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SECTION  1.  GENERAL 


hi  Purpose  of  the  Evolutionary  Implementation  Plan  (EIP).  The  purpose  of  the  AFIRMS 
EIP  is  to  provide  the  necessary  planning  and  scheduling  information  to  life-cycle 
management  personnel,  functional  users,  and  data  processing  personnel  for  developing  and 
implementing  AFIRMS  worldwide.  The  design,  development,  installation,  and  operation  of 
the  AFIRMS  system  are  evolutionary.  They  are  accomplished  in  an  incremental  series  of 
modular  steps  for  HQ  USAF,  each  Air  Force  major  command  (MA3COM)  headquarters, 
intermediate  headquarters  (where  appropriate),  and  wing/base/squadron  elements.  The 
EIP  provides  a  top-down  frame  of  reference  to  shape  the  evolution  and  implementation  of 
AFIRMS.  This  EIP  document  provides  the  highest  level  definition  of  the  implementation 
plan.  It  provides  the  overall  organization,  top  level  schedules,  and  explanation  of  the 
work  efforts  required  for  AFIRMS  implementation.  Annex  A  contains  the  AFIRMS 
Management  Plan.  Appendix  A  contains  an  overview  of  MA3COM  implementation 
schedules.  The  other  EIP  Appendices  detail  how  the  implementation  will  evolve  within 
each  MAJCOM.  The  EIP  is  intended  to  be  a  "living"  document  which  is  updated 
periodically  to  reflect  the  current  AFIRMS  implementation  planning. 


1.2  Project  References.  Accurate  assessment  of  force  readiness  and  sustainability  has 
been  a  constant  concern  of  Air  Force  Commanders  and  their  staffs.  This  concern  has 
been  supported  by  an  intensified  DoD-wide  interest  in  capability.  In  response,  the  Air 
Force  Directorate  of  Operations  and  Readiness  initiated  the  AFIRMS  Program.  AFIRMS 
has  been  under  development  through  a  learning  prototype  and  is  being  designed  to  provide 
Air  Force  Commanders  with  a  complete,  timely,  and  accurate  assessment  of  their 
operational  readiness  and  sustainability. 

The  Program  Management  Office  (PMO)  responsible  for  contract  management  of  the 
AFIRMS  Learning  Prototype  Phase  (LPP)  and  this  EIP  is  the  Data  Systems  Design  Office 
(DSDO/XO),  Gunter  Air  Force  Station  (AFS),  Alabama;  the  Office  of  Primary 
Responsibility  (OPR)  is  the  United  States  Air  Force  Readiness  Assessment  Group 
(AF/XOCiM).  Three  operational  centers  were  used  as  LPP  testbed  sites:  The  Pentagon, 
Washington,  D.C.;  Headquarters  United  States  Air  Forces  Europe  (HQ  USAFE),  Ramstein 
Air  Base  (AR),  Germany;  and,  the  52nd  Tactical  Fighter  Wing  (TFW),  Spangdahlem  AB, 
Germany. 


m 


a.  AFIRMS  Data  Requirements  Document,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1983.  (Unclassified) 

b.  AFIRMS  Economic  Analysis,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 

31  May  1985.  (Unclassified) 

c.  AFIRMS  Evolutionary  Implementation  Plan,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

d.  AFIRMS  Functional  Description,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

e.  AFIRMS  HQ  USAF  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

f.  AFIRMS  HQ  USAF  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

g.  AFIRMS  HQ  USAFE  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

h.  AFIRMS  HQ  USAFE  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,,  31  May  1985.  (Unclassified) 

i.  AFIRMS  Product  Descriptions,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 
31  May  1985.  (Unclassified) 

j.  AFIRMS  System  Specification,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 
31  May  1985.  (Unclassified) 

k.  AFIRMS  Transform  and  Model  Descriptions,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

l.  AFIRMS  Wing  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

m.  AFIRMS  Wing  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

n.  System  Interface  Design  for  the  AFIRMS  LPP  and  the  Combat  Fuels 
Management  System  (CFMS),  SofTech,  Contract  No.  F49642-83-C-0022, 

28  February  1985.  (Unclassified) 

o.  AFR  700-5,  Information  Systems  Requirements  Board,  9  November  1984. 
(Unclassified) 

p.  System  Interface  Design  for  the  AFIRMS  LPP  and  the  Air  Force  Operations 
Resource  Management  System  (AFORMS),  SofTech,  Contract  No. 
F49642-83-C-0022,  2  November  1984.  (Unclassified) 

q.  AFR  700-2,  Information  Systems  Planning,  26  October  1984.  (Unclassified) 

r.  Automated  Data  Processing  (ADP)  Security  Policy,  Procedures,  and 
Responsibilities,  AFR  205-16,  1  August  I9S4.  (Unclassified) 
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s. 


AFR  300-4,  Vol.  4,  Air  Force  Data  Dictionary,  1  May  1984.  (FOUO) 


t.  Automated  Data  Systems  (ADS)  Documentation  Standards,  DoD-STD-7935.1, 

24  Aprii  1984.  (Unclassified) 

u.  Department  of  Defense  Dictionary  of  Military  and  Associated  Terms,  JCS  Pub  1, 

24  April  1984.  (Unclassified) 

v.  AFR  700-1,  Managing  Air  Force  Information  Systems,  2  March  1984.  (Unclassified) 

w.  AFIRMS  LPP  ADP  Security  Plan,  SofTech,  Contract  No.  F49642-83-C-0022, 

13  February  1985.  (FOUO) 

x.  AFR  300-4,  Vol.  3,  Air  Force  Data  Dictionary,  15  August  1983.  (FOUO) 

y.  Sustainability  Assessment  Model  (formerly  CAC)  Functional  Description,  Contract 
No.  F33700-83-G-002005701,  8  April  1983.  (Unclassified) 

z.  AFR  700-3,  Information  Systems  Requirements  Processing,  30  November  1984. 
(Unclassified) 

aa.  MIL-STD-480  Configuration  Control-Engineering  Changes,  Deviations,  and  Waivers. 

bb.  MIL-STD-483  Configuration  Management  Practices  for  Systems,  Equipment, 
Munitions,  and  Computer  Programs. 

*  cc.  U5AF  Operational  Major  Command  Functional  Area  Requirement  (FAR),  SofTech, 

Contract  No.  F49642-82-C-0045,  15  December  1982.  (Unclassified) 

dd.  Unit  Combat  Readiness  Reporting  (C-Ratings)  (Unit  Status  and  Identity  Report 
(UNITREP),  RCS:HAF-XOO(AR)7112(DD)),  AFR  55-15,  22  November  1982. 
(Unclassified) 

*  ee.  USAFE  Annex  to  USAF  FAR,  5ofTech,  Contract  No.  F49642-82-C-0045, 

20  August  1982.  (Unclassified) 

*  ff.  AFIRMS  FAR,  SofTech,  Contract  No.  MDA-903-76-C-0396,  14  March  1980. 

(Unclassified) 

gg.  AFIRMS  Data  Analysis,  SofTech,  15  February  1979.  (Unclassified) 

hh.  User's  View  of  AFIRMS,  SofTech,  1  November  1978.  (Unclassified) 

ii.  AFR  700-9,  Information  Systems  Standards,  Volume  I,  15  March  1985. 

(Unclassified) 

jj.  U.S.  Air  Force  Glossary  of  Standardized  Terms,  AFM  11-1,  Vol.  1,  2  January  1976. 
(Unclassified) 

kk.  AFIRMS  Data  Automation  Requirement  (DAR),  Final,  SofTech,  Contract  No. 
MDA-903-76-C-0396,  14  March  1980.  (Unclassified) 


♦Material  contained  in  references  cc  and  ee  expands  on  that  found  in  reference  ff. 


11.  AFR  300-12,  Procedures  For  Managing  Automated  Data  Processing  Systems  (ADPS) 
Vol.  II,  2  September  1977.  (Unclassified) 

mm.  AFR  300-15,  Automated  Data  Systems  Project  Management,  16  January  1978. 
(Unclassified) 

nn.  AFR  300-2,  Managing  the  USAF  Automated  Data  Processing  Program, 

24  April  1980.  (Unclassified) 

oo.  AFR  300-6,  Automatic  Data  Processing  Resource  Management,  11  July  1980. 
(Unclassified) 

pp.  AFR  178-1,  Economic  Analysis  and  Program  Evaluation  For  Resource  Management, 
14  December  1979.  (Unclassified) 

qq.  AFP  178-8,  Economic  Analysis  Procedures  Handbook,  19  May  1981.  (Unclassified) 


1.3  Abbreviations  and  Acronyms. 


AAC  -  Alaskan  Air  Command 

AB  -  Air  Base 

ADS  -  Automated  Data  Systems 

AF  -  Air  Force 

AFIRMS  -  Air  Force  Integrated  Readiness  Measurement  System 
AFLC  -  Air  Force  Logistics  Command 

AFM  -  Air  Force  Manual 

AFORMS  -  Air  Force  Operations  Resource  Management  System 

AFP  -  Air  Force  Pamphlet 

AFR  -  Air  Force  Regulation 

AFRES  -  Air  Force  Reserve 

AFS  -  Air  Force  Station 

AFW'IS  -  Air  Force  World  Wide  Military  Command  and  Control  System 

Information  System 


ANG 

A  TO 

CAMS 

CAS 

CCB 

CE 

CF  VIS 


Air  National  Guard 
Air  Tasking  Order 

Core  Automated  Maintenance  System 
Combat  Ammunition  System 
Configuration  Control  Board 
Civil  Engineers 
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CSMS 

- 

Combat  Supplies  Management  System 

DDN 

- 

Defense  Data  Network 

DoD 

- 

Department  of  Defense 

DPI 

- 

Data  Processing  Installation 

DRD 

- 

Data  Requirements  Document 

DSDO 

- 

Data  Systems  Design  Office 

EA 

- 

Economic  Analysis 

E&I 

- 

Engineering  and  Installations 

EDS 

- 

European  Distribution  System 

EIFEL 

- 

NATO  Command  and  Control  System 

EIG 

- 

Engineering  Installation  Group 

E1P 

- 

Evolutionary  Implementation  Plan 

FD 

- 

Functional  Description 

HQ 

- 

Headquarters 

LAN 

- 

Local  Area  Network 

LPP 

- 

Learning  Prototype  Phase 

VI  AC 

- 

Military  Airlift  Command 

M A 3COM 

- 

Major  Command 

NAF 

- 

Numbered  Air  Force 

NATO 

- 

North  Atlantic  Treaty  Organization 

OPLAN 

- 

Operation  Plan 

OPR 

- 

Office  of  Primary  Responsibility 

PACAF 

- 

Pacific  Air  Forces 

PCR 

- 

Programmed  Communications  -  Electronics  Requirement 

PD 

- 

Product  Descriptions 

PMO 

- 

Program  Management  Office 

POL 

- 

Petroleum,  Oil  and  Lubricants 

POM 

- 

Program  Objective  Memorandum 

SAC 

- 

Strategic  Air  Command 

SAM 

- 

Sustainability  Assessment  Module 

SBSS 

- 

Standard  Base  Supply  System 

STD 

- 

Standard 

TAC 

- 

Tactical  Air  Command 

TAF 

- 

Tactical  Air  Forces 

tascform 

- 

Technique  for  Assessing  Comparative  Force  Modernization 

TFW 

USAF 

USAFE 

WIN 

WIS 

WMP 

WSAM 

WSMIS 

WWMCCS 


Tactical  Fighter  Wing 

United  States  Air  Force 

United  States  Air  Forces  Europe 

WWMCCS  Intercomputer  Network 

WWMCCS  Information  System 

War  and  Mobilization  Plan 

Weapon  System  Assessment  Model 

Weapon  System  Management  Information  System 

World  Wide  Military  Command  and  Control  System 
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SECTION  2.  INTRODUCTION  TO  AFIRMS 


This  section  provides  a  brief  introduction  to  the  Air  Force  Integrated  Readiness 
Measurement  System  (AFIRMS).  A  more  complete  description  is  provided  in  the  AFIRMS 
Functional  Description. 


AFIRMS  Synopsis. 


2.1.1  Key  AFIRMS  Concepts.  AFIRMS  is  an  automated,  tasking  based,  capability 
assessment  system.  As  such,  AFIRMS  evaluates  unit  and  force  capability  to  perform 
tasked  missions  based  on  the  availability  of  specific  resources. 


a.  The  conceptual  requirements  for  AFIRMS  are  two-fold: 

(1)  Assessment  of  combat  capability  against  specific  tasking.  The  user  can 
assess  unit/force  combat  capability  against  any  planned  or  ad  hoc  tasking, 
e.g.,  War  Mobilization  Plan  (WMP),  Operation  Plan  (OPlan),  Fragmentary 
Order,  Air  Tasking  Order  (ATO),  Contingency  Plan,  etc. 

(2)  Assessment  of  combat  capability  based  on  budget  appropriations. 

AFIRMS  provides  a  tool  for  computing  long-term  readiness  and 
sustainability  trends,  spanning  two  to  six  fiscal  years.  This  tool  permits 
comparison  of  readiness  and  sustainability  by  fiscal  year  and  can 
therefore  highlight  the  impact  of  appropriation  changes.  Thus,  changes  in 
funding  are  related  to  changes  in  force  readiness  and  sustainability.  Also, 
senior  Air  Force  decision  makers  are  supported  during  budget 
deliberations  and  Air  Force  budget  allocations. 

b.  AFIRMS  implementation  has  two  key  concepts: 

(I)  Integrated  approach  to  tasking  based  capability  assessments.  AFIRMS  has 
two  integrative  dimensions.  First,  ail  applicable  resources  and  their  usage 
interactions  are  considered.  For  example,  in  sortie  capability  assessment, 
AFIRMS  evaluates  capability  in  terms  of  all  four  essential  resource  types 
(aircrew,  aircraft,  munitions,  fuel),  their  interdependencies,  and  their 
generative  components  (such  as  spares  for  aircraft,  training  qualifications 
for  aircrew,  load  crews  for  munitions,  and  hot  pits  for  fuel).  Second, 
other  automated  systems  (such  as  the  Combat  Supplies  Management 
System  (CSMS),  Combat  Fuels  Management  System  (CFMS),  Weapon 
System  Management  Information  System  (WSMIS),  etc.)  outputs  are 
integrated  into  capability  assessment  calculations  through  system 
interfaces  between  those  systems  and  AFIRMS. 
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(2)  Data  Quality  Assurance.  Capability  assessment  is  no  better  than  the  data 
upon  which  it  is  based.  Therefore,  AFIRMS  emphasizes  a  user  orientation 
toward  quality  assurance  of  source  data.  Unit  and  other  data  input  level 
users  are  provided  effective  tools  to  accomplish  their  daily  activities  and 
therefore  develop  a  vested  interest  in  AFIRMS  data  currency  and 
validity.  Capability  assessment  data  can  then  be  extracted  for  use  by 
higher  or  parallel  users  with  maximum  confidence  in  its  validity. 


2.1,2  AFIRMS  Functions.  Four  basic  AFIRMS  functions  combine  to  assess  readiness 
capability: 


a.  Translate  Tasking.  As  a  tasking  based  capability  assessment  system,  tasking 
must  be  converted  into  a  standard  format  recognized  by  AFIRMS.  Tasking  is 
defined  in  AFIRMS  to  the  unit  level  and  may  consist  of  actual  tasking,  standard 
tasking,  or  contingency  tasking.  Any  of  these  taskings  can  be  defined  within 
specified  WMP  or  OPlan  constraints,  at  the  option  of  the  user..  Likewise,  the 
tasking  may  be  defined  by  the  user  for  present,  historic  or  future  requirements. 

b.  Define  Resources.  The  resource  definition  function  of  AFIRMS  ensuies  that 
information  about  inventory  status  is  available  and  accurate.  Wherever 
possible,  this  data  is  obtained  by  interface  with  other  functional  systems.  As 
with  tasking,  resource  information  can  be  defined  for  actual,  hypothetical,  or 
contingency  situations,  either  present,  historic,  or  future. 

c.  Determine  Ability  to  Perform.  Determining  the  force's  ability  to  perform  is 
the  essential  function  of  AFIRMS.  The  tasking  and  resource  data  are  processed 
to  determine  how  much  of  the  specified  tasking  can  be  accomplished  with  the 
resources  available.  Ability  to  perform  is  evaluated  in  terms  of  the  task  metric 
(sorties, etc.)  and  the  cost  metric  (dollars)  to  provide  readiness/sustainability 
and  dollars  to  readiness  assessments. 

d.  Aggregate,  Analyze  and  Present  Data.  Aggregation,  analysis  and  presentation 
ensure  the  proper  grouping  and  display  of  data  to  provide  useful  information  at 
the  unit,  major  command  and  HQ  USAF.  Aggregation  refers  to  the  creation  of 
a  composite  understanding  of  capability  for  several  units. 


2.2  AFIRMS  Documentation.  A  set  of  nine  types  of  documents  describes  AFIRMS.  A  list 
of  these  AFIRMS  documents  is  provided  below  along  with  a  short  description  of  the 
particular  aspects  of  AFIRMS  which  are  addressed  by  each  document. 


Functional  Description  (FD).  The  FD  provides  the  description  of  AFIRMS 
concepts  in  user  terms.  It  is  the  baseline  document  which  ties  the  AFIRMS 
documents  together. 
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b.  Economic  Analysis  (EA).  The  EA  states  AFIRMS  estimated  costs.  It  explains 
the  cost  factors  of  AFIRMS  implementation  alternatives  and  states  the 
recommended  alternative. 

c.  Evolutionary  Implementation  Plan  (EIP).  The  EIP  details  the  current  plan  for 
AFIRMS  implementation.  It  describes  the  time  sequence  of  the  implementation 
by  functional  blocks,  organizations  and  work  phases  (analysis,  development, 
installation,  etc.). 

d.  System  Specification.  The  AFIRMS  System  Specification  adds  the  design 
requirements  to  the  functional  concepts  in  the  FD.  It  divides  the  system  into 
subsystems  (HQ  USAF,  HQ  USAFE  (MAJCOM),  and  Wing  (unit))  and  assigns 
functions  required  within  each  subsystem.  The  system  specification  details  the 
overall  architecture,  intersite  interface  gateways,  processing  logic  flows  and 
the  communications  network  specifications. 

e.  Subsystem  Specifications,  There  are  three  AFIRMS  subsystem  specifications: 
HQ  USAF,  HQ  USAFE  (M A JCOM/numbered  Air  Force),  and  the  Wing 
(unit/squadron).  Subsystem  specifications  detail  the  specific  design  and/or 
performance  requirements  of  the  system  at  that  level.  Design  details  cover  the 
architecture,  required  functions,  the  functional  users,  intrasite  interface 
gateways,  and  applicable  processing  logic  flows. 

f.  Database  Specifications.  There  are  three  AFIRMS  database  specifications:  HQ 
USAF,  HQ  USAFE  (M AJCOM/numbered  Air  Force),  and  Wing  (unit/squadron). 
These  specifications  describe  the  database  architecture,  size,  and  content,  as 
well  as  logical  data  relationships  for  the  functions  performed  at  each  of  the 
AFIRMS  levels. 

g.  Data  Requirements  Document  (DR D).  The  DRD  identifies,  categorizes,  and 
groups  the  generic  types  of  data  used  in  AFIRMS.  It  also  defines  each  type  of 
AFIRMS  data  element  (attribute  class). 

h.  Product  Descriptions  (PDs).  The  PDs  visually  portray  the  products  which 
implement  the  AFIRMS  functions  as  input  and  output  tools. 

Transform  and  Model  Descriptions.  The  Transform  and  Model  Descriptions 
Document  defines  how  AFIRMS  calculates  the  output  data  from  the  input  data. 
Specific  algorithmic  calculations  are  provided.  Logical  groups  of  algorithms 
forming  AFIRMS  models  and  transforms  are  described. 
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SECTION  3.  EVOLUTIONARY  IMPLEMENTATION  PLAN  OVERVIEW 


3.1  Office  of  Primary  Responsibility.  The  Readiness  Assessment  Group,  HQ 
USAF/XOOIM,  is  the  Office  of  Primary  Responsibility  (OPR)  for  managing  the 
evolutionary  implementation  of  AFIRMS.  The  U.S.  Air  Force  Data  Systems  Design  Office 
(DSDO)  is  the  Program  Management  Office  (PMO)  and  is  responsible  for  the  design, 
development,  testing,  and  implementation  of  AFIRMS.  The  PMO  also  coordinates  the 
efforts  of  the  Air  Staff  and  MA3COM  OPRs  to  ensure  the  user's  requirements  are 
implemented  in  AFIRMS. 

3.2  Implementation  Elements.  The  AFIRMS  EIP  is  composed  of  segments,  blocks,  and 
phases.  HQ  USAF  and  each  MAJCOM  is  a  segment  within  the  overall  AFIRMS 
implementation.  Each  segment  is  composed  of  a  number  of  blocks.  A  block  is  a  specified 
set  or  subset  of  functional  requirements  to  be  implemented.  These  requirements  are 
normally  represented  by  a  specific  set  of  AFIRMS  applications  products  (screens  and 
processes),  communications  capabilities,  and  interface  requirements.  Each  block  is 
composed  of  five  phases.  The  completion  of  the  five  phases  implements  the  functional 
requirements  identified  for  that  block.  The  phases  of  a  block  contain  the  task  detailing 
necessary  for  the  analysis/requirements  definition,  development,  installation,  operation, 
and  the  integration/management  of  the  functional  block  capabilities.  Figure  3-1  shows 
the  relationship  between  the  segments,  blocks,  phases,  and  time.  This  figure  shows  that 
the  EIP  is  composed  of  segments  (Segment  H  =  HQ  USAF  and  Segment  U  =  USAFE)  which 
have  functional  capabilities  implemented  as  sequential  blocks  over  time. 
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Figure  3-1.  AFIRMS  EIP  Structure 


SEGMENT 

BLOCK 

PHASE 


The  HQ  USAF  or  a  MAJCOM  "slice"  of  AFIRMS.  (HQ  USAF  and 
USAFE  are  the  first  two  segments.) 

A  module  of  AFIRMS  functional  capability.  (Block  1  functionality  for 
HQ  USAF,  and  for  USAFE  =  enhanced  LPP  functional  capabilities.) 

A  group  of  tasks  required  to  accomplish  a  block.  (Analysis, 
Development,  Installation,  Operation,  Integration/Management.) 


The  AFIRMS  set  of  readiness  and  capability  assessment  tools  available  to  each 
functional  user  are  tailored  to  the  work  requirements  and  status  information  needs  of  that 
user.  The  evolutionary  aspect  of  AFIRMS  implementation  has  two  meanings.  Both 
meanings  relate  to  time-phased  sequences  of  activities.  First,  the  implementation  of  the 
initial  blocks  of  AFIRMS  functional  capability  has  a  sequential  timetable  over  the  HQ 
USAF  and  the  MAJCOMs.  The  initial  block  within  each  segment  of  the  evolutionary 
implementation  provides  a  core  capability  for  the  HQ  USAF,  MAJCOM  headquarters,  and 
operating  units  of  each  MAJCOM.  The  core  capability  may  be  different  for  Block  1  of 
each  EIP  segment  since  additional  capabilities  or  enhanced  capabilities  will  become 
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available  over  time.  The  core  capabilities  for  the  first  segment  implementations  are 
those  of  the  LPP  as  modified  to  reflect  the  lessons  learned  during  LPP  trials  and  tests. 
Second,  the  implementation  provides  for  an  upgrade  of  the  core  capabilities  in  subsequent 
blocks.  These  subsequent  blocks  provide  additional  functional  capabilities  beyond  the  core 
functions,  accommodate  changing  missions  or  environments,  and  take  advantage  of 
improved  data  processing  technology. 


3.3  Schedule.  In  order  to  reduce  the  total  implementation  time  required  for  AFIRMS,  the 
block  development  efforts  for  several  MA3COM  segments  must  occur  in  parallel. 

An  optimum  schedule  for  implementation  is  shown  in  Figure  3-2.  This  schedule  shows 
a  sequencing  of  segments  and  of  blocks  within  each  segment.  The  schedule  is 
unconstrained  by  resources  and  represents  a  maximum  effort  to  implement  all  MAJCOMs 
simultaneously. 
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Figure  3-2.  AFIRMS  Master  Implementation  Schedule  (Optimum) 
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The  planned  AFIRMS  implementation  schedule  is  shown  in  Figure  3-3.  This 
implementation  is  constrained  by  program  funding.  It  allows  for  identification  of  funding 
sources  for  the  Air  National  Guard  (ANG)  and  the  Air  Force  Reserve  (AFRES)  segments. 
Depending  on  funding  availability,  the  implementation  schedules  for  these  segments  may 
be  moved  forward  in  time.  Likewise,  other  MA3COM  funding  initiatives  could  adjust 
schedules  toward  the  "optimum"  schedule  shown  in  Figure  3-2. 


SECTION  4.  SUMMARY  OF  EVOLUTIONARY  IMPLEMENTATION 


» 


4.1  Segments  of  the  Evolutionary  Implementation  Plan,  The  evolutionary  implementation 
of  AFIRMS  is  broken  down  into  segments,  blocks,  and  phases.  A  segment  represents  the 
implementation  plan  for  AFIRMS  at  HQ  USAF  or  at  a  MAJCOM.  Each  segment  is 
composed  of  a  number  of  blocks  that  represent  a  set  or  subset  of  functional  requirements 
to  be  implemented.  The  blocks  are  broken  down  into  phases;  the  phases  represent  the 
tasks  necessary  to  implement  the  functional  requirements  of  a  block.  HQ  AFCC,  in 
coordination  with  the  Air  Staff  and  MAJCOM  OPRs,  is  responsible  for  the  implementation 
of  AFIRMS.  The  following  tasks  provide  a  framework  within  which  implementation 
priorities  can  be  set  and  progress  monitored. 

a.  Development  and  accomplishment  of  the  AFIRMS  Program  Management  Plan. 

b.  Development  and  accomplishment  of  the  EIP  and  its  segment  plans. 

c.  Preparation  and  Update  of  the  Data  Project  Plan. 

d.  Development  and  accomplishment  of  the  Configuration  Management  Program. 

e.  Program  Objective  Memorandum  (POM)  and  budget  advocacy. 

f.  Implementation  scheduling. 

g.  Supervision  of  the  system  developers  (whether  Air  Force  or  contractor). 

h.  Staff  supervision  of  worldwide  system  operation  and  maintenance. 

i.  Problem/action  reporting. 


4.2  Blocks  of  the  Evolutionary  Implementation  Plan.  A  block  is  a  specific  set  of  AFIRMS 
functional  capabilities.  Blocks  are  defined  in  terms  of  statements  of  functional  need, 
which  are  based  upon  the  AFIRMS  Functional  Description.  Functional  needs  may  be 
readiness/sustainability  assessment  tools,  interfaces  with  other  MAJCOM/Air  Force/DoD 
systems,  or  enhancements  to  these  types  of  capabilities.  Blocks  are  defined  and  scheduled 
in  the  AFIRMS  Management  Plan  and  are  controlled  by  the  Configuration  Management 
Program. 
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Selection  of  functional  requirements  for  implementation  in  a  particular  block  in  a 
specific  MAJCOM  segment  is  made  from  the  list  of  unsatisfied  requirements  for  that 
MAJCOM.  This  list  of  unsatisfied  requirements  will  be  compiled  by  the  AFIRMS  HQ 
USAF  Office  of  Primary  Responsibility  (OPR)  and  the  Program  Management  Office 
(PMO),  from  problem/action  reports  received  from  the  MAJCOMs,  from  the  set  of 
available  or  projected  AFIRMS  products  as  they  are  developed  and  from  specific 
statements  of  requirement  from  MA3COM  representatives. 

4.3  Phases  of  Evolutionary  Implementation  Plan  Blocks.  A  phase  is  one  of  five  sets  of 
actions  necessary  to  achieve  the  functional  capabilities  of  a  block  in  the  AFIRMS  EIP. 
The  five  phases  are  Analysis/Requirements  Definition,  Development,  Installation, 
Operations,  and  Integration/Management.  These  phases  are  not  sequential  but  represent 
the  logical  flow  of  activities  within  a  block.  Activities  of  one  phase  may  occur 
concurrently  v  i*h  activities  of  another  phase. 

4.3.1  Analysis/Requirements  Definition  Phase.  The  Anaiysis/Requirements  Definition 
Phase  consists  of  those  steps  necessary  to  design  and  specify,  in  detail,  the  functional 
needs  for  a  block  in  the  EIP.  The  completion  of  this  phase  results  in  the  updating  or 
development  of  system/subsystem  specifications,  database  specifications,  and  supporting 
documents  such  as  a  Block  Development  Plan  and  a  Block  Test/Verification/Validation 
Plan.  It  also  provides  information  to  update  the  EIP,  Economic  Analysis,  Transform  and 
Model  Descriptions,  Product  Descriptions,  and  the  Data  Requirements  Document, 

4.3.2  Development  Phase.  The  Development  Phase  consists  of  those  steps  necessary  to 
create  the  products  that  accomplish  the  functional  needs  for  a  block  in  the  EIP.  The 
completion  of  the  Development  Phase  results  in  creation,  and  stand-alone  testing,  of  the 
program  coding  necessary  to  accomplish  the  functional  requirements.  The  Development 
Phase  also  provides  the  Training  Program,  Maintenance  Program,  Installation  Program, 
and  the  user/operator  documents  required  for  the  block  implementation. 


4.3.3  Installation  Phase.  The  Installation  Phase  consists  of  those  steps  necessary  to  place 
the  functional  capabilities  into  operation.  The  completion  of  this  phase  results  in  the 
modification  of  facilities  (if  necessary),  acquiring  and  placing  communications  lines  and 
computer  hardware  into  service,  installing  software,  testing  tne  system,  changing 
operations  to  the  new  system,  and  conducting  training. 


4.3.4  Operations  Phase.  The  Operations  Phase  consists  of  those  steps  necessary  to 
operate  and  maintain  the  operational  system.  System  maintenance  (hardware,  software, 
and  database)  is  a  prime  concern  during  this  phase.  The  completion  of  the  Operations 
Phase  is  established  by  the  implementation  of  a  new  block. 


4.3.5  Systems  Integration/Management  Phase.  The  Systems  Integration/Vlanagement 
Phase  consists  of  those  steps  necessary  to  monitor  and  guide  the  block  installation  in 
accordance  with  the  AFIRMS  Management  Plan.  Actions  in  this  phase  are  concurrent 
with  the  Analysis,  Development,  Installation,  and  Operations  Phases.  Actions  in  the 
Systems  Integration/Management  Phase  result  in  control  of  the  block  implementation, 
preservation  of  system  integrity,  and  in  monitoring  of  the  worldwide  AFIRMS  operations. 


4,4  Systems  Interface  Candidates.  AFIRMS  interfaces  are  required  with  MAJCOM 
unique,  Air  Force  standard,  and  DoD  systems  in  order  to  collect  the  resource 
summary/status  data  necessary  to  produce  the  AFIRMS  readiness  assessment  tools.  These 
interfaces  are  also  required  in  order  to  communicate  between  and  within  the  Air  Force 
organizational  structure.  Interfaces  with  communications  systems,  logistics  management 
systems  of  the  Air  Force  Logistics  Command  (AFLC),  personnel  management  systems,  and 
command/control  (tasking)  systems  provide  necessary  AFIRMS  data  while  minimizing  data 
system  redundancies.  The  plan  for  AFIRMS  interface  with  other  data  systems  is 
contained  in  the  Systems  Interface  Program  which  is  part  of  the  AFIRMS  Management 
Plan.  Systems  with  which  AFIRMS  is  likely  to  interface/integrate  include: 

SYSTEM  INTERFACE  AREA 

Air  Force  Information  System  AFIRMS  architecture 

Architecture  Efforts  and  environment 


Air  Force  Operations  Resource 
Management  System  (AFORMS) 


Aircrew  status 


SYSTEM 


INTERFACE  AREA 


Base  Level  Data  Automation 
Program  (PHASE  IV) 

Combat  Ammunitions  System 

Combat  Fuels  Management  System  (CFMS) 

Combat  Supplies  Management  System  (CSMS) 

Contingency  Operations/Mobility 
Planning  and  Execution  System  (COMPES) 

Core  Automated  Maintenance  System  (CAMS) 

Dyna-METRIC/Mini  Dyna-METRIC  Model 

Electronic  Information  Command  and  Control 
System  for  Operational  Readiness  of  the 
Luftwaffe  (EIFEL) 

European  Distribution  System  (EDS) 

Local  Area  Network  Efforts  (LAN) 

Logistics  Capability  Measurement  System  (LCMS) 

Standard  Air  Force  Small  Computer  Requirements 
Contract  Efforts 

Standard  Base  Supply  System  (SBS5) 

Technique  for  Assessing  Comparative  Force 
Modernization  (TASCFORM) 

VI  ar  Mobilization  P'an  Upda^  T  System 

Weapon  Svstem  Management  Information  Svstem 
(W'SMIS) 

W  W  MCCS  Information  System  (W'IS/AFWIS) 


Data  integration 

Munitions  Status 

Combat  fuels  inventory  and 
status 

Spares  status 

Tasking  and  force  structure 

Spares,  maintenance  support 
personnel  status 

Spares  capability 

Tasking  and  force  structure 

Spares  status 
Communications  (local) 

Spares  status 
Hardware 

Spares,  fuels,  personnel  status 
Force  modernization 

Tasking  and  force  structure 
Spares  capability 

Communications  (long-line) 


The  "ideal"  interface  posture  for  AFIRMS  requires  electronic  interface  with  USAF 
support  systems  (particularly  logistics  support  and  tasking  systems),  DoD  systems 
(particularly  communications  systems),  and  allied  systems  (tasking  systems)  in  a 
multi-level  security  classification  environment.  These  interfaces  must  be  defined  and 
controlled  in  order  to  be  easily  reconfigurable/relocatable.  Such  an  approach  to  the 
interfaces  accommodates  changing  force  structure  or  changing  beddown  locations,  and 
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facilitates  reconstitution  in  case  of  battle  damage  or  sabotage.  There  are  impediments  to 
implementation  of  an  ideal  interface  posture  for  AFIRMS.  For  example,  "stove-pipe" 
functional  systems  require  tailored  interfaces  for  each  logical  interface  where  file 
structures  and  inputs/outputs  are  embedded  in  applications  and  where  non-standard  data 
elements  and  codes  are  used.  Also,  information  access  policies  which  address  security, 
privacy,  copyright,  data  integrity,  and  evaluation/certification  issues  impede  the  ideal 
interface  implementations. 

A  number  of  programs  are  working  in  the  direction  of  standardization.  In  large 
measure,  the  progress  of  AFIRMS  interface  with  other  systems  will  hinge  on  the  pace  of 
tne  Defense  Data  Network  (DDN),  Automated  Message  Processing  Exchange  (AMPE), 
LANs,  SCOPE  EXCHANGE/DIAL,  PHASE  IV  base-level  automation,  and  other  programs 
associated  with  the  USAF  Information  System  architecture.  These  efforts  will  form  the 
ideal  AFIRMS  interface  mechanism  as  other  systems  evolve  to  conform  to  the 
architecture. 

Other  efforts  in  standardization  cover  the  areas  of  Database  Management  Systems 
(DBMS)  and,  in  particular,  a  common  data  interchange  format.  The  common  data 
interchange  format  allows  AFIRMS  to  be  designed  modularly,  with  generic  interfaces  that 
can  communicate  with  current  and  future  systems.  The  International  Standards 
Organization  (ISO)  Standard  821 1  (Data  Descriptive  File,  DDF)  and  CCITT's  Draft 
Recommendation  (Presentation,  Transfer,  Syntax,  and  Notation)  are  two  examples  of  data 
interchange  formats  that  can  be  adopted  as  AFIRMS  standards.  All  information  passed  to 
and  from  AFIRMS  would  be  required  to  be  in  the  standard  data  interchange  format. 

Since  ideal  interfaces  between  AFIRMS  and  other  systems  will  not  be  available  during 
the  initial  blocks  of  AFIRMS,  interim  interface  solutions  must  be  attempted  in  order  to 
maintain  momentum  in  implementing  AFIRMS.  At  the  HQ  USAF  and  MAJCOM  levels, 
interim  interface  with  systems  outside  the  headquarters  is  via  AUTODIN,  DDN,  and/or 
WWMCCS/WIS.  Within  these  levels,  interfaces  are  hardwired. 

At  unit  levels,  interim  interfaces  with  systems  outside  the  AFIRMS  are  hardwired  in 
controlled  mode  security  operations.  If  controlled  mode  security  is  not  available, 
interfaces  to  unclassified  systems  are  air  gap. 
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During  Block  1  implementation,  planning  and  design  for  Block  2  are  conducted.  Part 
of  Block  2  planning  includes  a  review  of  status  of  DoD  and  U5AF  Information  System 
architecture  implementation  in  order  to  capitalize  on  realized  interface  capabilities.  For 
the  next  five  years  or  so,  AFIRMS  will  address  each  interface  requirement  ad  hoc  during 
the  analysis  phase  of  each  block. 


4.5  System  Configuration  Control.  System  configuration  control  incorporates  those 
procedures  necessary  to  establish  and  maintain  a  specified  level  of  operational  capability 
in  the  AFIRMS  system.  Three  levels  of  configuration  control  are  required  to  coincide 
with  the  three  levels  of  operational  control  over  AFIRMS  activities:  units  (wings), 
MAJCOMs  and/or  Numbered  Air  Forces  (NAFs),  and  HQ  USAF. 

Configuration  control  responsibilities  of  each  level  in  the  AFIRMS  system  are 
addressed  in  this  section  of  each  Segment  Plan.  Also,  special  control  requirements 
relating  to  interfacing  AFIRMS  with  other  existing  information  systems  are  detailed.  The 
specific  role  of  configuration  control  in  each  of  the  implementation  phases  will  be 
detailed  separately  in  the  appropriate  section.  The  general  requirements  addressed  in 
AFR  300-15,  Chapter  2,  serve  as  the  basis  for  the  development  and  continuing  operation 
of  the  AFIRMS  Configuration  Management  Program. 

Details  of  the  Configuration  Management  Program,  including  Problem/Action 
Reporting,  are  found  in  Appendix  B  of  this  document. 


4.5.1  HQ  USAF  Configuration  Control.  Configuration  management  procedures 
incorporate  provisions  for  the  following: 

a.  -3FIRMS  Configuration  Control 

b.  AFIRMS  Baseline  Management 
-\FIRML  iterfacing  Requirements/Status 

d.  AFIRMS  .uditing  and  Review  Procedures 

e.  Problem/Action  Reporting  System 


The  focus  of  control  at  the  HQ  LSAF  level  is  to  define  the  minimum  operating 
requirements  for  the  entire  AFIRMS  system  while  providing  operating  flexibility  to  lower 

levels. 


+  -b 
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Change  control  procedures  are  In  accordance  with  AFR  300-12,  Vol  11.  An  HQ  USAF 
level  Configuration  Control  Board  (CCB)  provides  the  focal  point  through  which  the 
applicability,  approval,  and  timing  of  proposed  changes  is  established.  This  board  is 
composed  of  one  member  from  the  operations  or  readiness  assessment  office  of  each 
MAJCOM  and  one  member  of  each  major  staff  element  participating  in  AF1RMS.  The 
board  is  chaired  by  the  AFIRMS  OPR. 

4.3.2  MAJCOM  Configuration  Control.  The  AFIRMS  ADPS  manager  performs 
configuration  management  in  conjunction  with  the  DSDO.  MAJCOM  level  configuration 
controls  implement  the  HQ  USAF  configuration  control  requirements.  MAJCOM  level 
control  procedures  serve  to  monitor  the  procurement,  installation,  and  operating 
activities  of  AFIRMS  within  the  elements  of  the  MAJCOM.  These  procedures  isolate  and 
document  AFIRMS  deficiencies  and  provide  a  mechanism  for  reporting  these  deficiencies 
to  HQ  USAF  configuration  control  authorities  for  disposition  and  action.  MAJCOM 
controls  ensure  that  all  hardware  and  software  contractors  providing  AFIRMS  related 
capabilities,  adhere  to  the  functional  and  product  baselines  established  by  the  AFIRMS 
Configuration  Management  Program  and  that  the  AFIRMS  system  is  operated  and 
maintained  in  accordance  with  the  baselines.  Specific  major  command  configuration 
control  authority  responsibilities  are  identified  in  the  appropriate  EIP  Segment  Annex. 

4.3.3  Wing  Configuration  Control.  The  Data  Processing  Installation  (DPI)  Manager  at 
Wing  level  ensures  configuration  control  for  AFIRMS.  Wing  procedures  detail  controls  for 
the  routine  operation  and  maintenance  of  AFIRMS  and  ensure  that  functional  and  product 
baselines  are  maintained.  Wing  level  control  procedures  isolate  and  document  AFIRMS 
deficiencies  and  report  these  deficiencies  to  MAJCOM  and  DSDO  configuration  control 
authorities  for  disposition  and  action.  Specific  wing  configuration  control  responsibilities 
are  identified  in  the  appropriate  major  command  EIP  segment  annex. 


SECTION  5.  ANALYSIS/REQUIREMENTS  DEFINITION  PHASE 


5.1  Survey  Users.  The  Analysis/Requirements  Definition  Phase  consists  of  those  steps 
necessary  to  design  and  specify,  in  detail,  the  functional  needs  programmed  for  a  block  in 
the  EIP.  These  steps  are  the  identification  or  confirmation  of  metrics,  the  design  of  the 
functional  architectures  with  associated  cost  benefit  analysis,  system  design,  installation 
planning,  and  preparation  of  specifications.  Survey  efforts  identify  functional  users  of 
AFIRMS,  identify  general  functional  requirements,  accomplish  the  preliminary  facilities 
survey,  and  facilitate  communication  between  the  systems  developer  and  the  end  user(s) 
of  the  system.  Visits  to  work  locations  are  accomplished  to  gain  first-hand  knowledge  of 
the  users'  requirements  and  their  contextual  environment.  Upon  arrival  at  the  survey 
site,  the  analysts  conduct  an  in-briefing  to  inform  the  AFIRMS  project  officer  and  other 
key  personnel  of  the  reason  for  the  visit  and  the  goals  of  the  user  survey.  The  analysts 
use  whatever  tools  are  necessary  to  survey  the  users.  Examples  are: 

a.  The  use  of  questionnaires.  Questionnaires  provide  a  means  of  collecting 

consistent  sets  of  information  from  a  large/number  of  people  in  a  short  period 
of  time. 

Interviewing.  Interview  questions  lead  to  discussions  about  the  current  and 
desired  future  systems,  both  formal  and  informal.  The  analysts  interview  a 
cross  section  cf  the  personnel  to  get  a  good  feel  for  the  users'  operation  and  the 
spectrum  of  user  requirements. 

c.  Review  of  Management  Indicators.  Organizations  use  a  variety  of  indicators  to 
assign  tasking  and  measure  productivity,  capability,  and  performance.  The 
analysts  inventory  those  indicators  carefully  to  determine  their  use,  the  source 
of  data,  methods  of  compilation,  and  relevance  as  possible  AFIRMS  metrics. 

d.  Preliminary  Analysis  of  the  Facilities.  The  analysts  note  the  working 
environment.  Many  operations  are  scattered  among  several  locations.  The 
analysts  determine  the  method  of  communication  and  the  interface 
requirements  between  operations  occurring  at  separate  locations.  Preliminary 
identification  of  available  facilities,  power  sources,  air  conditioning,  and  access 
routes  is  accomplished. 

When  the  survey  is  finished,  the  analyst  team  leader  conducts  an  exit  briefing  with 
the  AFIRMS  project  office  and  key  personnel  within  the  organization. 
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5.2  Identify/Confirm  Metric(s).  During  the  survey  of  the  users,  the  unit's  standards  or 
indicators  that  measure  tasking  and  performance  are  identified.  The  rationale  for  the 
metric,  the  source(s)  of  information,  and  the  use  of  particular  indicators  or  standards  by  a 
higher  headquarters  are  determined.  Some  metrics  may  be  for  local  use  only.  Other 
metrics  are  passed  to  higher  headquarters  for  consolidation,  analysis,  and  decision 
support.  Other  indicators  or  standards  may  be  used  as  productivity  measures.  These 
indicators  or  standards  are  of  primary  importance  to  AFIRMS.  They  integrate  resource 
requirements  to  achieve  the  desired  mission  results.  As  an  example,  the  metric  for 
tactical  air  forces  is  the  sortie.  The  sortie  integrates  the  essential  resource  components 
of  a  mission  (aircraft,  aircrew,  fuels,  and  missions).  It  also  provides  a  focus  for  the 
application  of  generative  resources  (such  as  spares)  which  are  elemental  to  providing  the 
basic  aircraft  resource. 


5.3  Design  Functional  Architecture.  A  functional  analysis  of  all  potential  AFIRMS  users 
determines  how  different  types  of  resource  data  affect  the  capability  of  a  Wing's  mission, 
and  how  the  different  users  (Wings,  MAJCOMs,  and  the  Air  Staff)  use  the  same  data  for 
their  particular  purposes.  A  structured,  "top-down"  approach  is  taken  for  the  functional 
architectural  design  once  the  "bottom-up"  requirements  analysis  has  been  accomplished. 
All  functional  areas  are  broken  down  to  sub-functions  in  enough  detail  to  describe  the 
relevant  activities.  In  examining  a  function,  the  analyst  gives  specific  attention  to  the 
interfaces,  both  into  and  out  of  the  functional  areas.  Analysis  also  determines  the 
organization  element  which  controls  the  various  activities.  Availability  and  sufficiency  of 
both  existing  communications  and  existing  automated  data  systems  establish  constraints 
and  requirements  for  the  functional  architecture.  The  functional  architecture  design 
provides  the  framework  for  the  development  of  system  design,  specifications,  and 
database  structures.  Specific  steps  necessary  for  functional  architectural  design  are 
described  in  subsequent  subsections. 


5.3.1  Select  AFIRMS  Products.  AFIRMS  Products,  which  have  been  developed,  relate  to: 

a.  Unit  and  base  level  status  information 

b.  Wing  level  resource  status  summary 

c.  Capability  assessment  model  (sortie  generation) 
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d.  Integrated  resource  capability  assessment 

e.  Individual  resource  capability  assessment 

f.  Dollar  costing  of  resource  allocations  against  requirements 

g.  "Optimization"  of  dollar  allocation  among  resources  to  maximize  capability. 

After  the  requirement  analysis,  the  available  AFIRMS  products  are  reviewed  to  see  if 
they  can  meet,  or  be  modified  to  meet,  the  various  functional  requirements. 

The  functional  architecture  includes  existing  or  modified  AFIRMS  products,  if 
applicable.  Use  of  those  products  reduces  the  system  development  time  considerably  and 
avoids  duplication  of  development  efforts. 


5.3.2  Design  Additional  Products.  The  user  survey(s)  may  identify  new  functional 
requirements  for  which  AFIRMS  products  are  not  yet  developed.  As  the  user  identifies 


requirements  that  have  not  been  previously  defined,  the  analyst  will  design  application 
modules  for  the  new  products  based  upon  thorough,  detailed  functional  requirements 
analysis.  It  should  be  emphasized  that  these  are  NEW  products  which  MAY  be  deferred 


for  implementation  in  subsequent  functional  block  product  development  phases. 


The  functional  analysis  that  establishes  the  functional  architecture  will  also  identify 
HQ  U5AF  or  MAJCOM  unique  requirements.  These  command  unique  requirements  are 
likely  to  be  the  primary  source  of  new  AFIRMS  products.  These  new  products  are 
identified,  designed,  and  specified  to  a  level  of  detail  that  will  allow  program  coding  to 
proceed. 


5.3.3  Define/Design  Interfaces.  Very  few,  if  any,  functional  areas  operate  in  isolation. 
During  the  survey  of  users,  interfaces  will  become  apparent.  There  are  inter  and  intra 
functional  interfaces.  Intra  functional  interfaces  are  internal  to  AFIRMS  or  AFIRMS 
users/sites.  An  inter  functional  interface  is  one  outside  of  AFIRMS.  The  inter  functional 
interface  links  AFIRMS  with  other  Air  Force  functional  areas  and/or  other  automated 
systems.  While  the  user  survey  will  uncover  the  obvious  interfaces,  less  obvious 
interfaces  may  be  identified  in  the  design  of  the  functional  architecture,  and  detailed 
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design  of  AFIRMS.  The  specifications  identify  the  method  of  interface  (air  gap, 
tape-to-tape,  hardwire)  along  with  the  impact  which  the  interface  development  will  have 
on  both  AFIRMS  and  the  external  system(s). 


5.3.4  Define  Functional  Baseline.  This  is  the  contract  between  the  user  and  developer. 
The  functional  baseline  includes  all  the  requirements  identified  in  the  user  survey  and 
requirements  analysis  efforts,  to  include  the  metrics  and  any  new  applications.  To  ensure 
the  accuracy  of  the  information,  the  baseline  is  certified  by  the  HQ  USAF  and  MA3COM 
configuration  control  authorities  before  any  development  work  starts.  With  baseline 
certification,  the  OPR/PMO  team  assumes  responsibility  for  new  block  development.  Any 
enhancement  to  the  block  functionality,  change  in  requirements,  or  additional 
development  efforts  must  be  approved  by  the  configuration  control  authorities. 


5.3.5  Design/Size  Database.  Design  of  the  AFIRMS  segment  database  consists  of  three 
stages:  conceptual  design,  logical  design,  and  physical  design.  A  complete  understanding 
of  the  relationships  that  exist  for  all  data  in  a  segment  is  needed  for  the  conceptual 
design.  Next,  the  conceptual  database  design  is  mapped  into  a  series  of  logical  database 
designs  from  each  different  user's  perspective.  The  physical  design  and  implementation 
of  this  logical  design  follow,  with  the  peculiarities  of  the  chosen  DBMS  establishing 
essential  guidelines  as  to  the  actual  structure  of  the  data. 

The  logical  database  design  does  not  normally  change  within  a  MAJCOM  segment 
unless  new  information  has  been  gathered.  From  the  outset,  it  should  reflect  similarities 
that  exist  in  all  MAJCOMs  for  maximum  consistency  from  segment  to  segment.  Minor 
changes  to  the  database  design  and,  correspondingly,  to  the  software  that  accesses  it,  are 
to  be  expected. 

Likewise,  the  logical  designs  should  reflect  as  much  similarity  between  segments  as  is 
possible.  Here,  even  more  variation  is  expected  because  of  some  of  the  fundamental 
differences  that  exist  among  MAJCOMs.  For  sites  within  a  segment,  excluding  the 
MAJCOM  Headquarters,  there  should  be  little,  if  any,  change  to  the  logical  designs.  That 
is  to  say,  all  wings  typically  have  the  same  functional  areas  and,  consequently,  AFIRMS 
data  requirements  within  those  functional  areas  are  the  same.  This  assumption  is 
probably  accurate  for  the  most  part,  but  minor  exceptions  should  be  expected. 
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Within  a  MAJCOM  segment,  the  physical  implementation  of  each  site's  database  is 
likely  to  vary  depending  on  the  priority  of  individual  needs.  Thus,  the  database  is 
optimized  with  available  DBMS  tuning  mechanisms  to  better  support  products  favored  at 
that  site.  A  goal  of  these  optimizations  is  that  very  little  or  no  change  need  be  made  to 
existing  AFIRMS  software  at  that  site. 

The  conceptual  and  logical  database  design  stages  of  the  AFIRMS  database  at  any 
given  site  in  a  particular  segment  will  occur  in  the  Analysis/Requirements  Definition 
Phase  of  the  initial  implementation.  Known  data  requirements  of  ail  functional  areas  of 
each  site  are  accommodated  during  this  phase.  Logical  database  changes  can  cause  major 
database  design  modifications  across  the  board.  Likewise,  switching  from  one  DBMS  to 
another  cannot  be  readily  accommodated.  Modifications  to  the  physical  design  of  the 
AFIRMS  databases  within  a  segment,  on  the  other  hand,  continue  for  tuning  purposes  and 
should  pose  no  major  problem. 

Sizing  estimates  are  gathered  during  each  design  stage,  approaching  more  realistic 
numbers  as  the  design  progresses.  A  reasonable  sizing  estimate  is  achievable  after  the 
logical  design  stage,  since  all  data  requirements  are  defined.  Once  again,  it  is  reasonable 
to  suggest  that  the  sizing  estimates  should  not  vary  greatly  from  one  site  to  another 
within  a  segment,  unless  one  site  possesses  many  more  resources  than  others.  After  a 
particular  DBMS  is  chosen  for  use  within  a  segment,  the  most  accurate  database  sizing 
estimate  can  be  made  since  actual  data  storage  needs  can  be  assessed  and  the  amount  of 
software  which  accesses  that  DBMS  can  be  better  estimated. 


5.4  Cost/Benefit  Evaluation.  The  objective  of  the  cost/benefit  evaluation  is  to  provide 
the  block  functional  capabilities  as  economically  as  possible  and  to  ensure  that  the  block 
implementation  is  constrained  by  the  budget  as  defined  and  refined  within  the  Economic 
Analysis  document  and  the  Management  Plan,  Volume  1  -  Program  Administration.  A 
Cost/Benefit  Evaluation  is  performed  for  each  segment  and,  if  required,  each  block  within 
each  segment.  The  purpose  of  the  evaluation  is  to  document  the  major  analysis  steps  for 
selecting  the  most  cost-effective  means  of  accomplishing  the  AFIRMS  objectives.  The 
first  Cost/Benefit  Evaluation  of  Block  1  implementation  for  each  segment  may  be 
included  in  a  Segment  Cost/Benefit  Evaluation  document  or  it  can  be  written  as  a 
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separate  document.  Regardless,  the  Block  1  Cost/Benefit  Evaluation  must  agree  with, 
and  provide  more  detail  to,  the  recommended  alternative  and  costs  selected  in  the 
Segment  Cost/Benefit  Evaluation.  The  Cost/Benefit  Evaluations  for  succeeding  blocks  in 
each  segment  must  accommodate  prior  Segment  and  Block  Evaluations. 

The  length  and  level  of  detail  in  the  Cost/Benefit  Evaluation  will  depend  on  the  total 
cost  of  the  implementation  alternatives  and  the  level  of  approval  required  in  AFR 
700-series  regulations.  AFR  178-1,  AFR  173-13,  and  AFP  178-8,  guide  the  evaluation 
study  methods  and  cost  figures. 


5.5  Design  System.  The  system  design  is  the  definition  of  the  relationship  among  the 
hardware  and  software  components  that  accomplish  the  functions  defined  in  the 
functional  architecture.  The  functions  of  the  DBMS,  applications  and  communications 
software,  and  hardware  (if  appropriate)  are  decomposed  into  subordinate  components 
modules.  The  hardware  and  software  modules  are  defined  in  sufficient  detail  to  produce 
the  system /subsystem  specifications.  The  decomposition  of  functions  is  accomplished 
using  structured  "top-down"  techniques,  which  concentrate  on  data  flow,  control,  and 
timing. 


5.6  Define  Installation  Requirements. 

5.6.1  Structures  Affected.  Buildings  scheduled  to  house  new  or  upgraded  equipment,  and 
specific  room  locations  within  the  buildings,  are  identified  in  this  section.  Once  the 
rooms  are  determined,  the  positioning  of  each  piece  of  equipment  within  the  room  is 
detailed  so  that  specific  installation  requirements  can  be  determined;  i.e.,  access  plan, 
location  of  power  plugs,  physical  altering  of  walls,  ceilings,  and  floors,  etc.  These 
requirements  are  updated  once  the  results  of  the  site  survey  are  available,  and  final 
determinations  of  site  installation  configurations  are  accomplished.  Specific 
responsibility  for  structural  modifications  is  assigned  in  this  section  of  each  Segment  Plan. 
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5.6.2  Power/Communications/TEMPEST  Requirements.  The  specific  hardware  placed  in 
each  room  determines  electrical  power  requirements  and  equipment  layout  plans  due  to 
possible  TEMPEST  spacing  requirements.  The  power  and  TEMPEST  requirements  for  a 
piece  of  hardware  selected  during  the  development  phase  may  be  determined  by 
referencing  the  manufacturer's  site  preparation  manual  or  similar  document.  These 
documents  provide  the  voltage,  amperage,  and  frequency  requirements  as  well  as  any 
TEMPEST  constraints  which  must  be  observed.  Inter  and  intra  site  communications 
requirements  are  derived  from  the  system  design.  Intra  site  communications  depend  upon 
the  number  of  functional  users  at  the  site  and  the  relationships  between  the  AFIRMS 
products  used  by  these  functional  areas.  Inter  site  communications  requirements  for 
connectivity  are  to  the  higher  level  AFIRMS  site,  to  the  remotely  located  elements  of  the 
site  organization,  and  to  either  the  higher  or  the  remote  elements  as  backup 
connectivity.  After  individual  requirements  are  identified,  they  are  aggregated  by  room 
in  order  to  detail  requirements  by  building.  These  requirements  are  updated  to  reflect 
any  approved  changes  to  the  installation  configuration  identified  during  the  site  survey. 
The  final  content  of  this  section,  in  each  Segment  Plan,  identifies,  or  provides  reference 
to,  the  detailed  electrical  requirements  for  the  installation,  and  assigns  specific 
responsibility  for  achieving  electrical/communications/TEMPEST  actions  necessary  to  the 
installation. 


5.6.3  Air  Conditioning  Requirements.  Typical  air  conditioning  requirements  may  be 
obtained  from  manufacturers'  site  preparation  manuals  which  are  representative  of  the 
expected  equipment.  These  requirements  are  specified  for  the  main  processor  and  other 
environmentally  sensitive  equipment,  such  as  intelligent  color  graphics  terminals. 
Combined-site  air  conditioning  requirements  are  derived  for  use  during  the  site  survey. 
These  requirements,  as  modified  by  the  findings  of  the  site  survey,  specify  the  air 
conditioning  installation.  Specific  responsibility  for  air  conditioning  services  is  assigned 
in  this  section  of  each  MAJCOM  Segment  Plan. 


5.6 A  Site  Surveys.  Once  the  facility,  power,  air  conditioning,  and  TEMPEST 
requirements  have  been  determined,  site  surveys  are  accomplished.  This  must  be 
scheduled  with  the  appropriate  Engineering  Installation  Group  (EIG)  or  Information 
Systems  Group  well  in  advance  of  the  planned  installation  date.  The  site  surveys 
determine  exactly  what  facility  modifications  are  required  to  accommodate  the  hardware 
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configurations.  Details  such  as  equipment  locations,  power  sources,  electrical  lines, 
communications  lines,  and  air  conditioners  are  confirmed.  Site  surveys  must  be  scheduled 
well  in  advance  in  order  to  accommodate  installation,  communications,  and  TEMPEST 
lead  times.  Responsibility  for  site  survey(s)  is  assigned  in  this  section  of  each  MAJCOM 
Segment  Plan. 


5.7  Prepare  Test/Verification/Validation  Plan.  A  Test/Verification/Validation  Plan  for 
the  segment  applicable  to  each  functional  block  implementation  provides  the  procedures 
by  which  AF1RMS  implementations  are  certified.  To  certify  the  block  implementation,  a 
number  of  actions  are  required.  After  the  site  surveys  have  been  completed  and  the 
system  has  been  installed,  each  site's  system  is  completely  tested,  both  stand-alone  and 
with  other  sites.  The  system  software  and  its  interfaces  with  other  software  modules, 
such  as  the  communications  software  and  the  database,  are  tested  and  verified  to  ensure 
that  they  perform  correctly.  The  communications  lines  between  the  various  sites  also  are 
tested  to  verify  that  data  update  notifications  are  received  when  sent  from  other  sites. 
Also,  data  transfer  from  Wing  level  to  MAJCOM  level  and  MAJCOM  level  to  Air  Staff 
level  is  verified  over  the  actual  communications  lines.  A  test  for  system  load  is 
performed  to  verify  the  capacity  under  which  the  system  can  successfully  run.  In 
addition,  time  tests  are  taken  to  verify  compliance  with  data  transaction  speed 
requirements  for  each  site.  Tests  involving  power  fluctuations  and  alternate  power 
sources  are  performed  to  verify  the  prevention  of  system  loss  due  to  failure  or  inadequacy 
of  backup  power  sources.  Security  tests  and  evaluations  are  integral  parts  of  the 
Test/ Verification/ Validation  Plan. 


5.3  Prepare  System/Subsystem  Specifications.  Once  the  analysis/requirements  definition 
and  system  design  have  been  completed,  and  the  functional  requirements  for  AF1RMS 
have  been  identified,  they  are  set  forth  in  system,  subsystem,  and  database 
specifications.  These  technical  documents  detail  the  requirements  to  be  satisfied  by  the 
block  implementation  effort. 


The  system  specification  (B-level)  ties  together  the  various  subsystems,  and  defines 
system/subsystem/external  interrelationships  and  interfaces.  The  system  B-level 
specifications  are  for  svsterns-wide  requirements  such  as  communications  protocols  and 
intersite  interface  gateways.  Subsystem  and  database  specifications  are  written  (or 
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updated)  for  each  system  implementation  site.  These  are  B-level  specifications.  These 
specifications  are  prepared  for  development  personnel,  and  thus  detail  the  environment 
and  design  elements.  Program  specifications  (C-level)  are  provided  as  annexes  to  the 
subsystem  specifications.  All  system/subsystem/database  specifications  are  prepared  in 
accordance  with  appropriate  Air  Force  Automated  Data  Systems  (ADS)  Documentation 
Standards. 

The  system/subsystem/database  specifications  provide  a  summary  of  the 
system/subsystem/database  characteristics  and  requirements.  They  contain  a  description 
of  the  system/subsystem  as  well  as  qualitative  and  quantitative  descriptions  of  how  the 
system/subsystem  functions  satisfy  user  requirements.  In  addition,  the  specification 
documents  furnish  descriptions  of  the  following: 

1)  The  equipment  (existing  as  well  as  new  equipment  to  be  procured)  required  for 
the  operation  of  the  system/subsystem. 

2)  The  support  software  (and  test  software,  if  required)  with  which  the  computer 
programs  to  be  developed  must  interact. 

3)  The  interfaces  with  other  applications  computer  programs. 

**)  System  security  considerations  such  as  the  levels  of  availability,  integrity,  and 
confidentiality  of  the  system  and  its  components. 

5)  A  presentation  of  overall  system/subsystem  controls. 

6)  The  operating  procedures  of  the  system. 

7)  The  logical  flow  of  the  system/subsystem. 

3)  System  inputs,  output  and  database. 

9)  The  functions  of  the  computer  programs  in  the  system/subsystem. 


SECTION  6.  DEVELOPMENT  PHASE 


The  Development  Phase  consists  of  those  steps  necessary  to  create  the  specified  products 
that  accomplish  the  functional  needs  programmed  for  a  block  in  the  E1P.  These 
development  steps  are  applications  development,  systems  software  development,  and 
systems  documentation  development. 

6.1  Develop  Applications  Software.  Applications  development  includes  adapting  existing 
AFIRMS  products,  developing  entirely  new  AFIRMS  products,  and  unit-testing  the 
resulting  code.  When  the  functional  requirements  of  a  block  development  can  be  satisfied 
by  existing  AFIRMS  products  or  by  modification  of  existing  products,  the  development 
effort  is  reduced.  The  AFIRMS  application  software  is  developed  in  logical  steps.  The 
development  steps  include  defining  the  program  logic,  writing  the  software  pseudo  code, 
transferring  the  pseudo  code  to  actual  code,  making  the  code  syntax  error-free,  linking 
the  code  with  any  external  files  or  libraries,  debugging  the  module  (removing  the  logic 
errors),  unit-testing  the  module,  and  finally  integrating  the  module  into  the  system  and 
performing  system  tests. 

6.2  Develop/Integrate  Systems.  This  task  is  an  overview  of  the  entire  development 
phase.  The  sub-tasks  require  an  integrated  view  of  the  requirements  and  development 
process. 

6.2.1  Cost/Benefit  Evaluation.  Detailed  applications  software  design  will  depend  on 
knowing  the  characteristics  of  the  operating  system,  hardware,  DBMS,  or  system 
utilities.  Therefore,  a  cost/benefit  evaluation  must  be  accomplished  early  in  the 
development  phase.  The  effort  to  make  final  determination  of  the  hardware  and  software 
for  development  and  implementation  must  be  done  in  a  manner  similar  to  a  standard 
economic  analysis,  as  described  in  AFR  178-1  and  AFP  178-S.  Detailed  research  into  the 
performance  of  potential  hardware  and  software  must  be  considered  from  the  perspective 
of  costs  and  benefits,  despite  the  human  tendency  for  this  effort  to  concentrate  solely  on 
the  technical  merits  of  products  that  are  readily  available.  Thorough  research  documents 
as  wide  a  range  of  alternatives  as  possible.  Software  design  and  pseudo-coding  will  then 
proceed,  before  the  hardware  and  systems  software  are  acquired. 


General  procedures  are  as  follows: 
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a.  Determine  constraints  imposed  by  requirements  and  Air  Force/ A  FIR  MS 
standards. 

b.  Determine  performance  requirements  of  unconstrained  system  and/or 
components. 

c.  Research  and  assess  available  hardware  and  software  products, 
particularly  those  available  from  Air  Force  or  DoD  standard 
procurements,  including  the  study  of  technical  articles  and  the 
interviewing  of  product  users. 

d.  Determine  development  task  load,  development  schedule,  and  operations 
and  maintenance  requirements  associated  with  each  alternative. 

e.  Document  costs/benefits  analysis  and  selection. 

Since  the  hardware  and  software  components  perform,  as  a  whole,  to  provide  the 
functions  and  system  support  required  by  the  application,  the  performance  requirements 
of  the  components  must  be  kept  in  the  perspective  of  their  contribution  to  the  whole 
system.  Where  the  specific  choice  of  components  is  not  constrained,  the  evaluators  are 
free  to  try  many  alternatives  for  the  most  cost-effective  life-cycle  system  performance. 


6.2. 1.1  Select  Hardware/Operating  System.  If  not  explicit  in  the  requirements 
documentation  produced  at  the  end  of  the  analysis/requirements  phase,  the  performance 
requirements  of  the  hardware  and  operating  system  must  be  defined.  System  simulation 
tools  are  advisable  to  aid  in  this  effort,  and  such  tools  may  be  available  from  the 
analysis/requirements  phase.  Characteristics  and  performance  criteria  of  the  hardware 
and  operating  system  considered  are: 

1)  Computer  and  Peripherals 

a.  Central  processing  unit  throughput 

b.  Main  memory  size  and  access  timing 

c.  On-line  disk  capacity  and  timing 

d.  Environmental,  electrical,  and  security  characteristics 

e.  Available  operating  systems 
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Life-cycle  maintenance  and  support,  including  future  modifications  and 
enhancements 


g.  Life-cycle  cost  efficiency  in  view  of  changing  technology. 

2)  Operating  System 

a.  Size  and  speed/overhead 

b.  Maturity/stability 

c.  Compatibility  with  security  requirements 

d.  Availability  of  compatible  DBMS  and  utilities 

e.  Compatibility  with  multiple  types  of  hardware 

f.  Life-cycle  maintenance  and  support,  including  future  modifications  and 
enhancements 

g.  Life-cycle  cost  efficiency  in  view  of  changing  technology. 

6.2. 1.2  Select  Database  System.  The  following  characteristics  are  examined: 

a.  Read  and  write  performance 

b.  Data  synchronization  and  file  lockout 

c.  Security  characteristics 

d.  Interfaces  to  programming  languages,  operating  system,  and  network 
software 

e.  Ease  of  database  expansion  and  schema  changes 

f.  Life-cycle  maintenance  and  support,  including  future  modifications  and 
enhancements 

g.  Life-cycle  cost  efficiency  in  view  of  changing  technology. 


6.2. 1.3  Select  System  Utilities.  System  utilities  include  the  following: 
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Network  software 
Graphics  utilities 
Compilers  and  debuggers 
Structured  design  aids 
Electronic  mail. 
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Because  of  the  wide  variety  of  tools  in  this  category,  the  evaluation  assigns  weights 
of  importance  to  each  component,  based  on  the  cost  impact  of  the  item.  The  importance 
of  certain  features  of  individual  components  is  weighed  against  the  cost  of  having  the 
development  team  work  without  the  item  or  develop  its  own. 


6.2.2  Integrate  Systems  Code.  The  applications  and  systems  code  is  written  in  a 
structured,  top-down,  design  manner,  properly  commented,  to  facilitate  the  necessary 
on-paper  walkthroughs,  and  stand-alone  testing.  The  code  is  then  integrated  with  the  rest 
of  the  system.  The  structural  top-down  design  of  the  software  and  the  appropriate 
walkthrough  checks  are  quality  assurance  mechanisms  which  help  it  identify  problem 
areas  for  resolution  prior  to  implementation.  Code  integration  consists  of  syntax  and 
logic  error  removal,  compilation,  and  linkage  with  any  system  routines  and  library  files  or 
software  modules.  External  interfaces  are  linked  to  the  system  code  within  software 
modules  (separate  spawned  processes),  library  files  or  library  routines,  and  external  (i.e., 
non-AFIRMS)  systems. 


6.2.3  Conduct  System  Developmental  Tests.  After  all  the  application  modules  are 
separately  tested  and  integrated  into  the  total  system,  the  total  system  must  be 
thoroughly  tested.  Successful  entry  into  the  system  must  be  made  properly.  User  login 
security,  the  main  processor(s),  communication  links,  and  each  application  module  must  be 
further  tested  within  the  total  system  environment.  User  access  rights  by  type  of  access 
(read,  write,  delete,  etc.)  must  be  verified.  All  interfaces  between  modules  are  tested. 
Data  input  and  output  processes  are  verified.  Data  update  processing  messages  are 
checked.  Database  updates  are  successfully  accomplished.  Proper  exit  of  the  system 
must  be  tested. 


6,2,4  Establish  Product  Configuration  Baseline.  Once  the  system  code  and  external 
interfaces  are  integrated  into  the  system  and  sufficient  testing  has  been  performed,  a 
baseline  version  of  the  system  is  produced  for  incorporation  at  all  affected  user  sites  at 
the  HQ  USAF,  WAJCO.Vl,  and  Wing  levels.  The  system  baseline  is  mandatory 
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for  consistency  throughout  all  AFIRMS  sites  and  for  understanding  problem/action 
reports.  This  baseline  system  must  be  formed  from  the  AFIRMS  core  system,  where  all 
modifications/developments  occur.  The  baseline  version  reflects  the  current  operational 
state  of  the  system;  it  contains  the  current  modifications  made  to  the  system.  Each 
version  of  the  baseline  system  is  appropriately  labeled  with  version  number,  date  of  issue, 
and  any  specific  characteristics  of  that  baseline  version. 


6.2.5  Establish  Problem/Action  Reporting  System.  In  order  to  record  possible 
deficiencies  with  the  system  or  to  record  modifications  that  system  users  request,  a 
problem/action  reporting  system  is  contained  within  the  AFIRMS  configuration  control 
svstem.  The  reporting  system  is  an  integral  part  of  the  AFIRMS  system  software, 
designed  ana  developed  for  this  purpose.  The  reporting  system  consists  of  procedures 
through  which  the  user  can  specify  his/her  requests  or  problems.  These  procedures  are 
directly  linked  with  a  file  on  the  system  within  which  the  information  can  be  stored  for 
later  review  by  the  AFIRMS  svstem  developers.  The  user  manual  clearly  and  concisely 
states  these  procedures.  The  manual  explains  the  interface  between  the  AFIRMS  system 
and  the  problem  /action  reporting  system.  It  also  explains  how  to  enter  and  exit  from  the 
reporting  svstem.  The  information  received  from  the  users  via  this  utility  can  then  be 
incorporated  into  the  AFIRMS  svstem  development  plans  in  an  organized  manner. 


6.3  Develop  System  Documentation. 

6.3.1  Prepare  Training  Plan/Manual(s).  The  timing  of  the  training  is  important  to  ensure 
that  the  user  is  prepared  to  operate  the  system  once  the  hardware  has  been  delivered, 
software  uploaded,  and  the  system  checked  out.  A  training  plan  is  required  that  specifies 
training  resoonsibilities  (-MA3COM  or  Air  Training  Command)  and  training  schedules; 
includes  a  course  syllabus;  and  identifies  training  duration,  location,  and  instructional  aids 
necessary  to  teach  the  course.  Classroom  instruction  with  maximum  "hands-on"  use  of 
the  new  system  is  desirable  for  the  initial  training.  This  reduces  student  apprehension  and 
gains  user  acceptance  of  the  new  hardware/software.  If  Air  Training  Command  (ATC)  is 
m  be  responsible  for  training,  ATC  must  be  brought  into  the  development  effort  earls  to 
ensure  that  instructors  are  available  to  prepare  the  training  program.  In  this  situation, 
the  MAlC'VM  retains  responsibilitv  for  training  administrative  actions,  such  as  preparing 
training  schedules,  arranging  for  classrooms  and,  if  possible,  consolidating  training  among 
several  -'FIRMS  sites. 
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6.3.2  Prepare  User/Operator  Manuals.  Manuals  are  probably  the  most  important 
documents  the  system  developer  produces.  After  the  user  has  been  trained  and  the 
system  installed,  the  user/operator  manuals  guide  the  system  operation.  Newly  assigned 
personnel  may  initially  rely  solely  on  the  manuals  to  learn  how  to  operate  the  system. 

The  manuals  start  with  instructions  on  how  to  turn  equipment  on  and  off.  The  manuals 
contain  simple  instructions  for  operating  AF1RMS  at  the  MAJCOM  or  Wing  level. 
Operating  procedures  for  the  system  software  and  hardware  products  are  provided  as  a 
combination  of  vendor-provided  documents  and  AFIRMS  user  manuals.  The 
vendor-supplied  documents  detail  hardware  and  system  software  procedures,  while 
AFIRMS  user  manuals  detail  functional  product  procedures  including  communications  and 
security.  The  manuals  are  written  in  sufficient  detail  to  enable  the  system  user  to 
respond  to  most  situations  he/she  may  encounter.  The  writer  of  the  manuals  should 
assume  that  the  user's  knowledge  of  automation  is  minimal. 

6.3.3  Prepare  Maintenance  Plan/Manuals.  Once  the  system  becomes  operational,  it  must 
be  maintained.  A  system  maintenance  plan  specifies  the  maintenance  functions  that  must 
be  performed,  equipment  required  for  these  functions,  a  schedule  for  specified 
maintenance,  and  responsibilities  for  training  operators.  An  accompanying  manual  lists 
maintenance  procedures  in  detail  for  the  technician's  reference.  The  manual  is  divided 
into  volumes  to  provide  clear,  concise  instructions  for  AFIRMS  system  maintenance  at  the 
HO  LSAF,  MAJCOM,  and  Wing  levels.  Maintenance  procedures  for  both  hardware  and 
software  are  addressed  as  a  combination  of  vendor  and  AFIRMS  supplied  documentation. 
The  vendor-provided  documentation  details  hardware  and  system  software  maintenance 
procedures,  while  AFIR  MS  documentation  includes  functional  product  maintenance  such 
as  data  backup  and  communications  and  security  software  recovery.  The  documentation 
provides  sufficient  detail  so  that  the  system  operator  can  respond  to  most  situations 
he/she  may  encounter.  The  documentation  assumes  that  the  operator's  knowledge  of  the 
system  is  minimal. 


6.3.4  Finalize  System  Program  Documentation.  When  the  system  passes  all  its  tests, 
final  modifications  need  to  be  made  to  the  documentation  before  it  is  released.  All 
documentation  must  accurately  reflect  the  system  as  actually  built.  This  particularly 
applies  to  the  system,  subsystem,  and  product  specif ications  since  these  documents,  along 
with  the  database  specifications,  form  the  svstem  or  subsystem  baseline. 
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SECTION  7.  INSTALLATION  PHASE 


The  Installation  Phase  consists  of  those  steps  necessary  to  place  into  operation  those 
functional  capabilities  programmed  for  a  block  of  the  EIP.  The  installation  steps  are  the 
modification  of  facilities;  installation  of  communications/hardware/software;  conduct  of 
training;  and  problem  reporting.  These  steps  implement  the  Installation  Plan  prepared 
during  the  Development  Phase  based  upon  requirements  identified  during  the  site  surveys 
of  the  Analysis  Phase.  These  steps  are  to  prepare  the  facility,  acquire  hardware,  install 
hardware  and  software,  train  users  on  system  operations,  and  report  problems  and  desired 
changes  after  the  system  is  operational.  Responsibilities  for  the  installation  actions  are 
assigned  for  these  actions  in  the  Segment  Plans  for  HQ  USAF  and  each  of  the  MAJCOMs. 


7.1  Installation  Procedures  and  Schedule.  Upon  completion  of  the  site  survey,  the 
schedules  for  the  procurement  of  needed  supplies,  electrical  work,  communications  links, 
and  facility  modifications  are  developed.  These  schedules  are  synchronized  with  the 
procurement  of  equipment,  delivery  of  equipment,  and  the  rest  of  the  installation  actions, 
such  as  software  installation  and  training  in  a  master  implementation  plan.  Responsibility 
for  establishing  and  accomplishing  the  installation  schedules  is  assigned  when  the 
schedules  are  established.  Since  the  schedules  were  established  during  the  Development 
Phase,  they  are  first  verified  and  updated  early  in  the  Installation  Phase.  Also,  some  of 
tb'*  more  drastic  facility  modifications  can  be  initiated  during  the  final  efforts  of  the 
Development  Phase. 

7.1.1  Facility  Modification.  Before  hardware  or  communications  equipment  can  be  fully 
installed,  the  facilities  must  be  modified  as  specified  in  the  site  survey. 

7.1.2  Communications  Lines  Installation.  The  schedule  for  running  communication's  lines 
can  overlap  the  end  of  facility  modification  schedules,  but  a  functional  area  cannot 
receive  its  lines  until  all  physical  modifications  have  been  performed  at  that  functional 
area's  location  and  at  the  central  node  location.  Ideally,  the  communications  lines 
installations  are  completed  at  the  same  time  as  any  room  modifications  are  done. 


7.1.3  Hardware  Installation.  Hardware  cannot  be  installed  and  unit-tested  at  a  location  until 
the  physical  modifications,  if  any,  are  completed  at  that  location.  Once  the  communications 
equipment  has  been  installed,  a  more  complete  test  of  the  hardware  can  be  performed. 


7.1.4  Software  Installation.  Once  the  hardware  has  been  installed,  the  software  can  be 
loaded  and  unit-tested.  Since  each  functional  area  workstation  contains  its  own  database,  the 
software  can  be  loaded  and  tested  on  the  workstation  prior  to  the  installation  of  the 
communications  lines,  if  necessary. 


7.1.5  Systems  Integration.  After  all  of  the  functional  area  workstations  have  been  tested 
individually,  and  all  of  the  intrasite  communications  lines  have  been  tested,  the  subsystem  is 
ready  to  be  integrated  and  tested  as  a  whole.  Once  this  testing  is  completed,  the  installed 
subsystem  is  ready  to  be  integrated  into  the  AFIRMS  system.  The  user  can  test  intersite 
communications  and  intersite  functions,  such  as  roll-up. 


7.2  Conduct  Training  Operations.  Prior  to,  or  concurrent  with,  systems  installations,  the 
appropriate  personnel  at  each  location  must  be  trained  in  its  use.  Hardware  maintenance 
training  is  provided  when  Air  Force  personnel  are  assigned  responsibility  for  hardware 
maintenance.  Final  arrangements  for  post-installation  assistance  are  made  during  an  initial 
period  of  system  operation. 

Training  required  includes  bringing  the  system  up  or  down,  including  accomplishing  cold 
or  warm  starts  and  how  to  recognize  system  hardware  problems  or  how  to  recover  from 
hardware  errors  which  might  occur  during  processing.  Use  of  specific  peripherals  such  as 
tape  drives,  console  printers,  line  printers,  screen  printers,  and  special  color  printers,  video 
projectors,  and  terminals  is  required. 

Training  in  the  functional  capabilities  and  use  of  the  system  is  also  accomplished.  This 
training  includes  identification  of  each  of  the  functions  in  the  system  and  their  relationships. 

Training  on  the  use  of  communication  devices  such  as  modems  or  fixed  plant  adaptors  is 
required.  In  addition,  training  must  include  instruction  for  proper  keying  and  operation  of 
encryption  devices  as  well  as  establishing  the  schedule  and  procedure  for  keying. 
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SECTION  8.  OPERATIONS  PHASE 


The  Operations  Phase  consists  of  those  steps  necessary  to  operate  and  maintain  the 
operational  system. 


8.1  System  Maintenance.  Maintenance  of  the  AFIRMS  hardware  and  software  is  the  joint 
responsibility  of  the  Air  Force  Data  Systems  Design  Office  (DSDO),  the  base,  and  the 
MAJCOM  in  which  the  hardware  is  installed.  Maintenance  difficulties,  or  improvements 
to  maintenance  procedures,  are  reported  via  the  Problem /Action  Reporting  System  (AFR 
300-2,  AFR  700-1). 


8.1.1  Software  Maintenance.  Because  AFIRMS  is  an  Air  Force  standard  system,  all 
software  maintenance  is  the  responsibility  of  the  Air  Force  DSDO.  Any  software  changes 
to  AFIRMS  will  be  made  in  accordance  with  AFM  300-1  2,  Vol.  II,  and  released  to  the  users 
by  the  DSDO. 


8.1.2  Hardware  Maintenance.  Hardware  maintenance  will  be  the  responsibility  of  the  Air 
Force  Data  Processing  Installation  (DPI)  manager  at  whose  base  the  hardware  is  located. 
The  terms  of  the  equipment  purchase  may  specify  vendor-provided  maintenance,  in  which 
case  the  preventive  and  remedial  maintenance  will  be  provided  by  the  vendor. 
Alternatively,  maintenance  support  may  be  provided  by  DPI  personnel  or  done  by  third 
party  contract.  The  DPI  will  administer  the  hardware  maintenance  program  in 
accordance  with  AFR  300-6  for  the  MA3COM-  or  Wing-level  AFIRMS. 


8.2  Problem /Action  Reporting.  Any  AFIRMS  software  difficulties  will  be  reported  in 
accordance  with  applicable  directives  by  the  MAOCOM  or  Wing  DPI  to  the  DSDO  Field 
Assistance  Branch  which  then  takes  the  necessary  action  to  solve  the  problem,  makes 
immediate  message  changes  if  necessary,  and  incorporates  the  changes  into  the  next 
major  release  of  the  system  to  worldwide  users.  Major  changes  to  a  system  must  be 
approved  by  the  Configuration  Control  Authority  for  placement  in  a  particular 
implementation  block  of  the  Segment  Plans  for  the  affected  major  commands  (AFR 
300-1  2,  Vol.  II). 


SECTION  9.  SYSTEMS  INTEGRATION/MANAGEMENT  PHASE 


The  System  Integration/Management  Phase  consists  of  those  steps  necessary  to  monitor, 
guide,  and  control  the  block  implementation,  preserve  system  integrity,  and  monitor 
worldwide  AFIR.VIS  operations.  (Details  of  the  System  Integration/Management  Phase  are 
to  be  developed  in  conjunction  with  the  AFIRMS  Management  Plan  (Appendix  B)  during 
the  period  6  June  through  30  September  1985.  Included  in  this  Phase  are  the  actions 
needed  to  test  and  incorporate  new  concepts  after  the  implementation  begins.) 


ANNEX  A.  AFIRMS  MANAGEMENT  PLAN 


The  Management  Plan  is  scheduled  to  be  developed  and  published  during  the 
operational  decision  phase;  6  June  through  30  September  19S5. 

The  Management  Plan  addresses  the  responsibilities  for  planning,  funding,  and 
controlling  blocks  of  AFIRMS  functionality,  whether  contracted  or  in-house.  This  plan 
defines/programs  the  blocks  of  AFIRMS  implementation  by  identifying  the  MAJCOM, 
level  of  resolution  for  resource/tasking  information  input  to  assessment  algorithms,  and 
external  system  interfaces  required.  The  block,  or  phases  of  a  block,  as  appropriate, 
define  the  unit  of  effort  in  the  management  plan.  The  plan  also  specifies  how  the  testing 
and  incorporation  of  new  concepts  will  be  handled  after  the  beginning  of  AFIRMS 
implementation. 


The  management  plan  consists  of  a  set  of  volumes,  each  of  which  addresses  a  specific 
aspect  of  AFIRMS  management.  These  volumes  are: 


Volume 


Subject 


1 

2 

3 

4 

5 

6 


Program  Administration 
Security  Program 

Configuration  Management  Program 
Systems  Interface  Program 
Training  Program 
Maintenance  Program 
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Notes:  1.  Lower  case  letters  indicate  current  work  under  the  LPP  contract  or 

work  programmed  for  the  LPP  transition  phase  (a  =  analysis, 
d  =  development).  Upper  case  letters  indicate  additional  work 
required  for  implementation  of  operational  AFIRMS  (A  =  Analysis, 
D  =  Development,  1  -  Installation,  O  =  Operations). 

2.  AFLC  Block  4  and  HQ  USAF  Block  3  are  continuing  systems 
integration  implementation  efforts  that  incorporate  interface 
requirements  of  other  major  commands. 


3. 


Integration/Management  Phases  for  each  segment/block  run 
concurrently  with  the  four  phases  shown  for  each  block  above. 


APPENDIX  F.  HQ  USAF  SEGMENT  PLAN 


SECTION  1.  GENERAL  PURPOSE 

This  appendix  to  the  EIP  provides  the  direction  for  implementing  AFIRMS  at  HQ  USAF. 
This  appendix,  along  with  the  basic  EIP,  provides  the  specific  organization,  detailed 
schedules,  and  responsibilities  for  work  reauired  to  implement  AFIRMS.  The  reader 
should  refer  to  the  basic  EIP  for  background  information,  overall  schedules,  and  general 
system  analysis/development  guidance.  The  HQ  USAF  appendix  to  the  EIP  is  intended  to 
be  a  "living"  document,  and  is  updated  periodically  to  reflect  the  current  HQ  USAF 
AFIRMS  implementation  planning. 
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SECTION  2.  EVOLUTIONARY  IMPLEMENTATION  PLAN  OVERVIEW 


2.1  Implementation  Elements.  The  HQ  USAF  AFIRMS  Segment  Plan  is  composed  of  a 
number  of  blocks,  each  with  a  set  of  phases.  Each  block  is  a  specified  set  or  subset  of 
AFIRM5  functional  products  which,  when  implemented,  provide  a  specific  level  of  ability 
within  the  AFIRMS  functional  capabilities.  AFIRMS  products  are  computer  programs 
which  accomplish  specific  processes  at  a  specified  level  of  detail,  within  a  basic  AFIRMS 
function.  A  block  of  AFIRMS  products  is  implemented  by  the  accomplishment  of  specific 
actions  within  five  phases.  These  phases  are: 

a.  Analysis/Requirements  Definition 

(Results  in  completion  of  subsystem  specifications) 

b.  Development 

(Results  in  completion  of  integrated/tested  program  coding) 

c.  Installation 

(Results  in  site  installations  of  hardware  and  software)  t 

d.  Operations 

(Results  in  use  of  the  installed  block  capabilities) 

e.  Systems  Integration/Management 

(Results  in  coordinated  accomplishment  of  all  phases  of  the  block  in  adherence 

to  the  AFIRMS  Management  Plan) 

2.2  Schedule.  The  HQ  USAF  implementation  plan  for  Block  1  will  be  completed  during 
the  analysis/requirement  definition  phase  for  Block  1. 


SECTION  3.  ANALYSIS/REQUIREMENTS  DEFINITION  PHASE 


3.1  Survey  Users.  Initial  user  surveys  were  performed  during  the  LPP.  The  primary  user 
identified  is  the  Readiness  Assessment  Group  (XQOIM).  Additional  user  survey  effort  is 
required  to  identify /confirm  additional  users,  such  as: 

a.  Logistics  Readiness  Center  and/or  Air  Staff  Logistics 

b.  Personnel  Readiness  Center 

c.  Contingency  Support  Staff 

d.  Air  Staff  Planning 

3.2  Identify/Conf irm  Metric(s).  The  capability  assessment  metric  for  HQ  USAF  Block  1 
is  the  sortie.  Therefore,  the  capability  assessment  function  of  HQ  USAF  Block  1  is 
limited  to  the  fighter/reconnaissance  units  for  which  the  sortie  is  the  metric  of  existing 
AFIRMS  capability  assessment  algorithms.  Metrics  for  other  types  of  units  have  not  yet 
been  confirmed.  MAJCOM  segment  implementations  will  define  additional  metrics,  as 
appropriate,  for  incorporation  into  subsequent  blocks  of  the  HQ  USAF  Segment  Plan. 

3.3  Design  Functional  Architecture.  The  design  of  the  HQ  USAF  Block  1  functional 
architecture  is  intended  to  provide  for  consolidation  and  refinement  of  the  functional 
capabilities  of  the  LPP.  The  focus  is  on  user  interface,  system  reliability,  error  handling, 
user  documentation,  and  others  which  are  necessary  to  turn  the  HQ  USAF  prototype 
architecture  into  an  operational  system  architecture  reflecting  the  lessons  learned  during 
the  LPP.  This  approach  provides  basic  AFIRMS  capabilities  to  HQ  USAF  as  quickly  as 
possible  and  establishes  a  sound  foundation  for  the  evolution  of  the  HQ  USAF  segment  of 
AFIRMS. 

3.3.1  Select  AFIRMS  Products.  HQ  USAF  Block  1  requires  the  implementation  of 


AFIRMS  products  to  provide: 


Unit  and  base  level  status  information. 

Wing  resource  status  summary. 

Sortie  generation  model. 

Integrated  resource  capability  assessments. 

Individual  resource  capability  assessments. 

Dollar  costing  of  resource  allocations  against  requirements 


The  operational  HQ  USAF  AFIRMS  products  providing  these  capabilities  are 
essentially  those  developed  and  refined  during  the  LPP.  Design  details  for  those 
functional  products  are  specified  in  the  HQ  USAF  Subsystem  Specification,  together  with 
the  product  descriptions  and  relevant  models/algorithms  referenced  therein. 

HQ  USAF  Block  2  requires  the  implementation  of  AFIRMS  products  to  provide  dollar 
optimization  of  resource  allocations  against  taking  resource  requirements.  A  new  HQ 
USAF  Subsystem  Specification  or  a  supplement  to  the  specification,  is  required  for  each 
subsequent  block  implementation. 


3.3.2  Design  Additional  Products.  Requirements,  if  any,  for  additional  products  depend 
upon  the  results  of  the  remaining  user  surveys.  The  intent  for  Block  1,  is  to  limit 
evolution  of  new  products  and  focus  more  on  accommodating  incremental  requirements 
with  adjustments  to  existing  products.  Entirely  new  product  requirements  identified  will 
be  designed  and  implemented  within  Block  2. 

3.3.3  Define/Design  Interfaces.  HQ  USAF  AFIRMS  Block  1  will  interface  with  WWMCCS 
and  DDN/AUTODIN  for  communications  with  MAJCOMs.  No  other  system  interfaces  will 
be  included  in  HQ  USAF  Block  1. 

HQ  USAF  AFIRMS  Block  2  will  interface  with  Air  Force  functional  systems  identified 
during  the  Block  1  Analysis  Phase.  Existing  systems  such  as  the  Wartime  Sortie  and 
Flying  Hour  Model  are  likely  interface  candidates. 


3.3.4  Define  Functional  Baseline.  The  functional  baseline  for  HQ  USAF  Block  1  is  an 
enhanced  version  of  the  LPP  functional  capabilities.  HQ  USAF  Block  1  requires  few,  if 
any,  products  in  addition  to  those  developed  during  the  LPP.  However,  several  LPP 
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In  addition,  system  architectural  enhancements  are  necessary  for  the  operational  system. 
The  more  significant  enhancements  are  of  three  types: 


a.  Correct  capability  assessment  shortcomings  inherent  to  existing  sortie 
generation  model  algorithms.  Level  of  detail  is  increased  somewhat  over  that 
of  the  LPP  level  of  resolution  for  the  same  four  basic  resource  categories:  type 
of  aircraft  (from  MD  to  MDS),  type  of  aircrew  (from  MD  to  MDS),  type  of  fuel 
(from  a  single  type,  JP4,  to  multiple  types).  For  type  of  munitions,  the 
resolution  remains  at  the  multiple  types  of  "whole  round"  levels. 

b.  Generalize  AFIRMS  product  parameter  selection  mechanisms.  (Dynamic 
definition  of  product  parameter  choices  integrated  with  user  file  management 
and  control  tools.) 

c.  Integrate  the  components  of  the  Tasking  Model  to  ensure  integrity  and 
consistency  of  tasking  translation  data  elements.  (Automate  the  user 
requirement  to  ensure  tasking  component  consistency.) 

These,  and  other  requirements  of  the  operational  system,  are  detailed  in  the  HQ 
USAF  Subsystem  Specification. 


3,3.5  Design/Size  Database.  HQ  USAF  Block  1  database  architecture  will  remain 
centralized  on  the  existing  minicomputer  in  the  Readiness  Assessment  Group  (XOOIM). 

All  HQ  USAF  user  data  needs  will  be  served  by  this  central  database.  Specific  design  and 
sizing  of  the  HQ  USAF  database  is  described  in  the  HQ  USAF  Database  Specification. 


3.4  Define  Alternative  Architectures.  The  feasible  alternatives  identified  in  the 
Economic  Analysis,  Annex  A,  for  HQ  USAF  are  summarized  as  follows: 


a.  LPP  enhanced  architecture,  dedicated  communications,  with  additional  user 
functions. 

0.  LPP  enhanced  architecture,  VtAVMCCS/ AUTODIN  communications,  no 
additional  user  functions. 

c.  LPP  architecture  (minimal  "fixes"  only,  no  enhancements),  \X  A  MCCS/Al  TOPIN' 
communications,  no  additional  user  functions. 


SOFfe 


3.5  Cost/Benefit  Evaluation. 

COSTS 


ALTERNATIVE 

ANALYSIS 

DEVELOPMENT 

EQUIPMENT 

COMM 

a 

high 

high 

high 

high 

b 

medium 

medium 

low 

high 

r 

low 

low 

low 

low 

BENEFITS 


ALTERNATIVE 

MOMENTUM 

SATISFY  USER(S) 

RESPONSIVENESS 

a 

low 

high 

high 

b 

medium 

medium 

medium 

r 

high 

low 

low 

3.6  Design  System.  The  recommended  alternative  from  the  AFIRMS  Economic  Analysis 
is  alternative  b.  Thus,  the  HQ  L'SAF  Block  1  operational  system  builds  upon  the  LPP 
svstem  design.  The  hardware  system  consists  of  the  existing  (LPP)  equipment  plus 
additional  line  printers  and  dumb  terminals  (if  any)  as  identified  in  the  final  user  surveys. 
The  software  system  consists  of  the  LPP  products  (corrected  and  enhanced)  to  the 
functional  baseline  defined  in  the  Development  Phase.  The  detailed  HQ  L'SAF  Block  1 
system  design  is  specified  in  the  HQ  L'SAF  Subsystem  Specification,  HQ  L'SAF  Database 
specification,  Product  Descriptions,  and  Transforms  and  Model  Descriptions  referenced  bv 
these  specifications. 


3.7  Define  Installation  Requirements.  Block  1  installation  requirements  are  basically 
completed.  The  hardware  to  support  the  LPP  is  in  place  and  forms  the  kernel  hardware 
suite  for  Block  1  of  HQ  L'SAF  operational  AFIRMS.  The  user  survey  may  identify 
additional  requirements,  such  as  additional  terminals,  that  are  to  be  incurporated  into 
existing  hardware  architecture. 

Block  2  may  require  additional  equipment  and  communications  lines  to  connect  with 
fhe  Air  Force  Data  Services  Center.  This  will  be  confirmed  in  the  Block  2  phases. 
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3.7.1  Structures  Affected.  Block  1  equipment  is  installed  and  operating.  There  is  no 
effect  on  a  structure,  other  than  securing  a  place  for  the  hardware  and  operator. 


3.7.2  Power/  Communications/TEMPEST  Requirements.  Block  1  basic  power /TEMPEST 
requirements  have  been  identified  and  provided  for  the  HQ  L'SAF  site.  Block  2  may 
require  additional  communications/TEMPEST  equipment.  Communication  requirements  to 
interface  with  the  first  major  command  implementations  are  identified  during  the 
Analysis  Phase  of  the  first  implementation  blocks.  Intrasite  and  external  systems 
interface  communications  requirements  must  also  be  identified  in  the  Analysis  Phase. 
Block  2  installation  phase  will  determine  additional  requirements. 


3.7.3  Air  Conditioning  Requirements.  Air  conditioning  is  adequate  to  meet  most  Block  1 
hardware  requirements.  The  hardware  is  being  operated  in  the  current  environment.  The 
air  conditioning  requirements  are  inadequate  for  personnel  operating  the  AFIRMS 
equipment.  Rlock  2  air  conditioning  requirements  analysis  will  address  this  shortcoming 
as  well  as  any  additional  air  conditioning  requirements. 


3 .7.U  Site  Surveys.  Block  1  AFIRMS  basic  hardware  is  installed  and  the  facilities  are 
considered  adequate.  Block  2  will  require  a  new  site  survey  to  determine  if  facility 
modif ications  are  required. 


3.8  Prepare  Test/Verification/Validation  Plan.  A  Test/Verification/Validation  Plan  will 
be  written  to  include  the  following: 

After  the  site  surveys  have  been  completed  and  the  system  has  been  installed,  each 
site's  system  is  sufficiently  tested,  both  stand  alone  and  with  other  sites.  The  system 
software  and  its  interfaces  with  other  software  modules  such  as  the  communications 
software  and  the  database  are  tested  and  verified  to  ensure  that  they  perform  correctly. 
The  comrr ■unication  lines  between  the  various  sites  also  are  tested  to  verify  that  data 
update  notifications  are  received  when  sent  from  other  sites.  Also,  data  transfer  frc 
VI  mg  level  to  VA.Ic'CV  level  and  MA.ICPV  level  to  Air  Staff  level  is  verified  over  the 


3&SM 


F-7 


actual  communication  lines.  A  test  for  system  load  is  performed  to  verifv  the  capacity 
under  which  the  system  can  successfully  run.  In  addition,  time  tests  are  taken  to  verify 
compliance  with  data  transaction  speed  requirements  for  each  site.  Tests  involving  power 
fluctuations  and  alternate  power  sources  are  performed  to  verify  the  prevention  of  system 
loss  due  to  failure  or  inadequacy  of  backup  power  sources. 

3.9  Prepare  System /Subsystem  Specifications.  Once  the  analysis/requirements  definition 
and  system  design  have  been  completed,  and  the  functional  requirements  for  AFIRMS 
have  been  identified,  they  are  set  forth  in  system,  subsystem,  and  database 
specifications.  These  technical  documents  detail  the  requirements  to  be  satisfied  by  the 
block  implementation  effort. 

The  svstem  specification  (B-level)  ties  together  the  various  subsystems,  and  defines 
svstem /subsystem /external  interrelationships  and  interfaces.  The  B-level  specifications 
are  for  svstems-wide  requirements  such  as  communications  protocols  and  intersite 
interface  gateways.  Subsystem  and  database  specifications  are  written  (or  updated)  for 
each  svstem  implementation  site.  These  are  B-level  specifications.  These  specifications 
are  prepared  for  development  personnel,  and  thus  detail  the  environment  ana  design 
elements.  Program  specifications  (C-level)  are  provided  as  annexes  to  the  subsystem 
specif ications.  All  system /subsystem/  database  specifications  are  prepared  in  accordance 
with  appropriate  Air  Force  Automated  Data  Systems  (ADS)  Documentation  Standards. 

The  svstem /subsystem /database  specif  ications  provide  a  summary  of  the 
system /subsystem /data  characteristics  and  requirements.  They  contain  a  description  of 
the  svstem /subsystem  as  well  as  qualitative  and  quantitative  descriptions  of  how  the 
svstem /subsystem  functions  satisfy  user  requirements.  In  addition,  the  specification 
documents  furnish  descriptions  of  the  following: 

1)  The  equipment  (existing  as  well  as  new  equipment  to  be  procured)  reautreq  for 
the  operation  of  the  system /subsystem. 

2)  The  support  software  (and  test  software,  if  required)  with  which  the  computer 
programs  to  be  developed  must  interact. 

3)  The  interfaces  with  other  applications  computer  programs. 


4)  System  security  considerations  such  as  the  levels  of  availability,  integrity,  and 
confidentiality  of  the  system  and  its  components. 

5)  A  presentation  of  overall  system/subsystem  controls. 

6)  The  operating  procedures  of  the  system. 

7)  The  logical  flow  of  the  system/subsystem. 

S)  System  inputs,  output  and  database. 

9)  The  functions  of  the  computer  programs  in  the  system/subsystem. 


tt? 


SECTION  4.  DEVELOPMENT  PHASE 


The  development  steps  required  to  create  the  specified  products  to  meet  the  functional 
requirement  of  a  block  are  outlined  in  the  Basic  EIP  (Section  6).  Two  additional  areas 
that  are  required  for  HQ  USAF  Implementation. 


4.1  Integrate  External  Interfaces.  External  interfaces  must  link  the  system  code  within 
software  modules  (separate  spawned  processes),  external  library  files  or  library  routines, 
and  external  (i.e.,  non-AFIRMS)  systems. 


4.2  Integrate  and  Unit  Test  Application  Modules.  In  the  top-down  approach,  the  total 
AFIRMS  system  is  not  integrated  as  a  whole;  rather  it  is  broken  into  functional 
application  modules  that  are  coded,  integrated,  and  tested  separately,  and  then  included 
into  the  whole.  After  each  application  module  has  successfully  performed  under  specific 
functional  tests,  it  is  then  integrated  into  the  rest  of  the  system  and  tested. 


The  LPP  installations  are  converted  to  operational  system  usage  as  detailed  in  subsequent 
sections. 

5.1.1  Facility  Modification.  Facility  modifications  were  minimal  for  the  LPP.  The 
equipment  is  in  place  and  no  additional  modifications  are  expected  in  Block  1. 

5.1.2  Communications  Lines  Installation.  Communications  lines  equipment  used  in  the 
LPP  are  being  retained  for  the  HQ  USAF  operational  AFIRMS.  Software  support  is 
provided  by  DECnet  and  KG84As  are  used  for  secure  transmission.  Modems  are  required 
at  the  sending  and  receiving  sites.  Transmission  is  either  analog  (ground)  or  digital 
(satellite),  or  a  combination  of  both. 

5.1.3  Hardware  Installation.  Block  1  hardware  is  basically  installed  and  ready  for  use  in 
the  operational  AFIRMS.  Equipment  currently  installed  consists  of; 

one  (1)  VAX  11/750 

one  (1)  Chromatics  CGC  7900  Color  Graphics  Computer 
one  (1)  VT-240  Color  Terminal 

two  (2)  DST-102  Black  and  White  Terminals  (TEMPEST) 

one  (1)  ACT-1  Color  Printer 

one  (1)  MATRIX  3000  Color  Graphic  Camera 

one  (1)  LA  100  Console 

Additional  hardware  installation  required  for  Block  1  consists  of: 


a. 

b. 


Color  graphics  terminals,  two  (2)  each:  Logistics  and  Planning 
Other  equipment  identified  during  the  analysis  phase  of  Block  I. 


SECTION  6.  DETAILED  HQ  USAF  SEGMENT  IMPLEMENTATION  SCHEDULE,  BLOCK  1 


The  HQ  L'SAF  detailed  segment  schedule  tor  Block  1  will  be  completed  during  the 
analysis/requirements  Definition  Phase,  Block  1. 
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APPENDIX  G.  MILITARY  AIRLIFT  COMMAND  (MAC)  SEGMENT  PLAN 


SECTION  1.  GENERAL  PURPOSE 

This  appendix  to  the  EIP  provides  the  direction  for  implementing  AFIRMS  at  HQ  M  AC. 
This  appendix,  along  with  the  basic  EIP,  provides  the  specific  organization,  detailed 
schedules,  and  responsibilities  for  work  required  to  implement  AFIRMS.  The  reader 
should  refer  to  the  basic  EIP  for  background  information,  overall  schedules,  and  general 
system  analysis/development  guidance.  The  HQ  MAC  appendix  to  the  EIP  is  intended  to 
be  a  "living"  document,  and  is  updated  periodically  to  reflect  the  recent  HQ  MAC 
implementation  planning. 


SECTION  2.  EVOLUTIONARY  IMPLEMENTATION  PLAN  OVERVIEW 


2.1  Implementation  Elements.  The  MAC  AFIRMS  Segment  Plan  is  composed  of  a  number 
of  blocks,  each  with  a  set  of  phases.  Each  block  is  a  specified  set  or  subset  of  AFIRMS 
functional  products  which,  when  implemented,  provide  a  specific  ability  level  within  the 
AFIRMS  functional  capabilities.  AFIRMS  products  are  computer  programs  which 
accomplish  specific  processes  at  a  specified  level  of  detail  within  a  basic  AFIRMS 
function. 

A  block  of  AFIRMS  products  is  implemented  by  the  accomplishment  of  specific  actions 
within  five  phases.  These  phases  are: 

a.  Analysis/Requirements  Definition 

(Results  in  completion  of  subsystem  specifications) 

b.  Development 

(Results  in  completion  of  integrated/tested  program  coding) 

c.  Installation 

(Results  in  site  installations  of  hardware  and  software) 

d.  Operations 

(Results  in  use  of  the  installed  block  capabilities) 

e.  Systems  Integration/Management 

(Results  in  coordinated  accomplishment  of  all  phases  of  the  block  and  in 
adherence  to  the  AFIRMS  Management  Plan) 

2.2  Schedule.  The  overall  MAC  implementation  plan  is  shown  in  Fi  ,ure  2-1. 
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Figure  2-1.  MAC  Blocks  1  &  2  Phase  Schedules 
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SECTION  3.  ANALYSIS/REQUIREMENTS  DEFINITION  PHASE 


3.1  Survey  Users.  The  Analysis/Requirements  Definition  Phase  consists  of  those  steps 
necessary  to  design  and  specify,  in  detail,  the  functional  needs  programmed  for  a  block  in 
the  EIP.  These  steps  are  the  identification  or  confirmation  of  metrics,  the  design  of  the 
functional  architectures  with  associated  cost  benefit  analysis,  system  design,  installation 
planning,  and  preparation  of  specifications.  Survey  efforts  identify  functional  users  of 
AFIRMS,  identify  general  functional  requirements,  accomplish  the  preliminary  facilities 
survey,  and  facilitate  communication  between  the  systems  developer  and  the  end  user(s) 
of  the  system.  Visits  to  work  locations  are  accomplished  to  gain  first-hand  knowledge  of 
the  users'  requirements  and  their  contextual  environment.  Upon  arrival  at  the  survey 
site,  the  analysts  conduct  an  in-briefing  to  inform  the  AFIRMS  project  officer  and  other 
key  personnel  of  the  reason  for  the  visit  and  the  goals  of  the  user  survey.  The  analysts 
use  whatever  tools  are  necessary  to  survey  the  users.  Examples  are: 


a.  The  use  of  questionnaires.  Questionnaires  provide  a  means  of  collecting  consistent 
sets  of  information  from  a  large/number  of  people  in  a  short  period  of  time. 

b.  Interviewing.  Interview  questions  lead  to  discussions  about  the  current  and  desired 
future  systems,  both  formal  and  informal.  The  analysts  interview  a  cross  section 
of  the  personnel  to  get  a  good  feel  for  the  users'  operation  and  the  spectrum  of 
user  requirements. 

c.  Review  of  Management  Indicators.  Organizations  use  a  variety  of  indicators  to 
assign  tasking  and  measure  productivity,  capability,  and  performance.  The  analysts 
inventory  those  indicators  carefully  to  determine  their  use,  the  source  of  data, 
methods  of  compilation,  and  relevance  as  possible  AFIRMS  metrics. 

d.  Preliminar\  Analysis  of  the  Facilities.  The  analysts  note  the  working 
environment.  Many  operations  are  scattered  among  several  locations.  The 
analysts  determine  the  method  of  communication  and  the  interface  requirements 
between  operations  occurring  at  separate  locations.  Preliminary  identification  of 
available  facilities,  power  sources,  air  conditioning,  and  access  routes  is 
accomplished. 


When  the  survey  is  finished,  the  analyst  team  leader  conducts  an  exit  briefing  with 
the  AFIRMS  project  office  and  key  personnel  within  the  organization. 


3.2  Identify/Confirm  Metric(s).  During  the  survey  of  the  users,  the  unit's  standards  or 


higher  headquarters  are  determined.  Some  metrics  may  be  for  local  use  only.  Other 
metrics  are  passed  to  higher  headquarters  for  consolidation,  analysis,  and  decision  support. 
Other  indicators  or  standards  may  be  used  as  productivity  measures.  These  indicators  or 
standards  are  of  primary  importance  to  AFIRMS.  They  integrate  resource  requirements  to 
achieve  the  desired  mission  results.  As  an  example,  the  metric  for  tactical  air  forces  is  the 
sortie.  The  sortie  integrates  the  essential  resource  components  of  a  mission  (aircraft, 
aircrew,  fuels,  and  missions).  It  also  provides  a  focus  for  the  application  of  generative 
resources  (such  as  spares)  which  are  elemental  to  providing  the  basic  aircraft  resource. 

3.3  Design  Functional  Architecture.  The  design  of  the  MAC  Block  1  functional  architecture 
will  provide  for  the  tailoring  of  core/basic  AFIRMS  functional  capabilities  to  MAC-unique 
needs  wh^re  applicable,  and  the  development  of  new  functional  products  as  required. 

A  functional  analysis  of  all  potential  MAC  AFIRMS  users  determines  how  different 
types  of  resource  data  affect  the  capability  of  a  Wing's  mission,  and  how  the  different  users 
(Wings,  MAJCOMs,  and  the  Air  Staff)  use  the  same  data  for  their  particular  purposes.  A 
structured,  "top-down"  approach  is  taken  for  the  functional  architectural  design  once  the 
"bottom-up"  requirements  analysis  has  been  accomplished.  All  functional  areas  are  broken 
down  to  sub-functions  in  enough  detail  to  describe  the  relevant  activities.  In  examining  a 
f  ction,  the  analyst  gives  specific  attention  to  the  interfaces,  both  into  and  out  of  the 
functional  areas.  Analysis  also  determines  the  organization  element  which  controls  the 
various  activities.  Availability  and  sufficiency  of  both  existing  communications  and  existing 
automated  data  systems  establish  constraints  and  requirements  for  the  functional 
architecture.  The  functional  architecture  design  provides  the  framework  for  the 
development  of  system  design,  specifications,  and  database  structure.  Specific  steps 
necessary  for  functional  architectural  design  are  described  in  subsequent  subsections. 


e.  Individual  resource  capability  assessment 

f.  Dollar  costing  of  resource  allocations  against  requirements 

g.  "Optimization"  of  dollar  allocation  among  resources  to  maximize  capability. 

After  the  requirement  analysis,  the  available  AFIRMS  products  are  reviewed  to  see  if 
they  can  meet,  or  be  modified  to  meet,  the  various  functional  requirements. 

The  functional  architecture  includes  existing  or  modified  AFIRMS  products,  if 
applicable.  L'se  of  those  products  reduces  the  system  development  time  considerably  and 
avoids  duplication  of  development  efforts. 


3.3.2  Design  Additional  Products.  The  user  survey(s)  may  identify  new  functional 
requirements  for  which  AFIRMS  products  are  not  yet  developed.  As  the  user  identifies 
requirements  that  have  not  been  previously  defined,  the  analyst  will  design  application 
modules  for  tne  new  products  based  upon  thorough,  detailed  functional  requirements 
analysis.  It  should  be  emphasized  that  these  are  NEW  products  which  MAY  be  deferred  for 
implementation  in  subsequent  functional  block  product  development  phases. 

The  functional  analysis  that  establishes  the  functional  architecture  will  also  identify 
MAC  unique  requirements.  These  MAC  unique  requirements  are  likely  to  be  the  primary 
source  of  new  AFIRMS  products.  These  new  products  are  identified,  designed,  and  specified 
to  a  level  of  detail  that  will  allow  program  coding  to  proceed. 


3.3.3  Define/Design  Interfaces.  MAC  AFIRMS  Block  2  will  interface  with  WAVMCCS  and 
DDN/AL'TODIN  for  communications  with  HQ  USAF  and  other  major  commands,  and  those 
Air  Force  functional  systems  identified  during  the  Block  1  Analysis  Phase. 

Very  few,  if  any,  functional  areas  operate  in  isolation.  During  the  survey  of  users, 
interfaces  will  become  apparent.  There  are  inter-  and  intra-functional  interfaces. 
Intra-functional  interfaces  are  internal  to  AFIRMS  or  AFIRMS  users/sites.  An 
inter-functional  interface  is  one  outside  of  AFIRMS.  The  interfunctional  interface  will  link 
AFIRMS  with  other  Air  Force  functional  areas  and/or  automated  systems.  While  the  user 
survey  will  uncover  the  obvious  interfaces,  less  obvious  interfaces  may  be  identified  in  the 
design  of  the  functional  architecture,  and  detailed  systems  specifications.  These  interfaces 
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are  documented,  specified,  and  included  in  the  design  of  AFIRMS.  The  specifications 
identify  the  method  of  interface  (air  gap,  tape-to-tape,  hardwire)  along  with  the  impact 
which  the  interface  has  on  the  users  of  both  AFIRMS  and  the  external  svstem(s). 

3.3.4  Define  Functional  Baseline.  The  functional  baseline  for  MAC  Block  2  is  the  set  of 
core  AFIRMS  functional  capabilities  adapted  for  support  of  MAC  functional 
reauirements.  Requirements  of  the  operational  system  are  to  be  detailed  in  the  MAC 
Subsystem  Specifications. 

This  is  the  contract  between  the  user  and  developer.  The  functional  baseline  includes 
all  the  requirements  identified  in  the  user  survey  and  requirements  analysis  efforts,  to 
include  the  metrics  and  any  new  applications.  To  ensure  the  accuracy  of  the  information, 
the  baseline  is  certified  by  the  HO  L'SAF  and  MAJCC'M  configuration  control  authorities 
before  any  development  work  starts.  U  ith  baseline  certification,  the  OPR/PMO  team 
assumes  responsibility  for  new  block  development.  Any  enhancement  to  the  block 
functionality,  change  in  requirements,  or  additional  development  efforts  must  be  approved 
by  the  configuration  control  authorities. 

3.3.3  Design/Size  Database.  Design  of  the  AFIRMS  segment  database  consists  of  threp 
stages:  conceptual  design,  logical  design,  and  physical  design.  A  complete  understanding 
of  the  relationships  that  exist  for  all  data  in  a  segment  is  needed  for  the  conceptual 
design.  Next,  the  conceptual  database  design  is  mapped  into  a  series  of  logical  database 
designs  from  each  different  user's  perspective.  The  physical  design  and  implementation 
of  this  logical  design  follow,  with  the  peculiarities  of  the  chosen  DBMS  establishing 
essential  guidelines  as  to  the  actual  structure  of  the  data. 

The  logical  database  design  does  not  normally  change  within  a  MAJCOM  segment 
unless  new  information  has  been  gathered.  From  the  outset,  it  should  reflect  similarities 
that  exist  in  all  MAJCOMs  for  maximum  consistency  from  segment  to  segment.  Minor 
changes  to  the  database  design,  and  to  the  software  that  accesses  it,  are  to  be  expected. 
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Likewise,  the  logical  designs  should  reflect  as  much  similarity  between  segments  as  is 
possible.  Here,  even  more  variation  is  expected  because  of  some  of  the  fundamental 
differences  that  exist  among  MAJCOMs.  For  sites  within  a  segment,  excluding  the 
MAJCOM  HQ,  there  should  be  little,  if  anv,  change  to  the  logical  designs.  That  is  to  sav, 
all  w  mgs  tvpicallv  have  the  same  functional  areas  ana,  consequently,  AF1R  MS  data 
recuirements  within  those  functional  areas  are  the  same.  This  assumption  is  probably 
accurate  for  the  most  part,  but  minor  exceptions  should  be  expected. 

A  ithin  a  MAJCOM  segment,  the  physical  implementation  of  each  site's  database  is 
likely  to  vary  depending  on  the  priority  of  individual  needs.  Thus,  the  database  is 
optimized  with  available  DBMS  tuning  mechanisms  to  better  support  products  favored  at 
that  site.  A  goal  of  these  optimizations  is  that  very  little  or  no  change  need  be  made  to 
existing  AFIRMS  software  at  that  site. 

The  conceptual  and  logical  database  design  stages  of  the  AFIRMS  database  at  anv 
given  site  in  a  particular  segment  will  occur  in  the  Analysis/Requirements  Definition 
Phase  of  the  initial  implementation.  Known  data  requirements  of  all  functional  areas  of 
each  site  are  accommodated  during  this  phase.  Logical  database  changes  can  cause  major 
database  design  modifications  across  the  board.  Likewise,  switching  from  one  DBMS  to 
another  cannot  be  readily  accommodated.  Modifications  to  the  physical  design  of  the 
AFIRMS  databases  within  a  segment,  on  the  other  hand,  continue  for  tuning  purposes  and 
should  pose  no  major  problem. 

Sizing  estimates  are  gathered  during  each  design  stage,  approaching  more  realistic 
numbers  as  the  design  progresses.  A  reasonable  sizing  estimate  is  achievable  after  the 
logical  design  stage,  since  all  data  requirements  are  defined.  Once  again,  it  is  reasonable 
to  suggest  that  the  sizing  estimates  should  not  vary  greatly  from  one  site  to  another 
within  a  segment,  unless  one  site  possesses  many  more  resources  than  others.  After  a 
particular  DBMS  is  chosen  for  use  within  a  segment,  the  most  accurate  database  sizing 
estimate  ran  be  made  since  actual  data  storage  needs  can  be  assessed  and  the  amount  of 
software  which  accesses  that  DBMS  can  be  better  estimated, 

3,4  Define  Alternative  Architectures.  Suitable  options  for  the  design  of  the  MAC  Block  2 
system  architecture  are  dependent  to  a  great  extent  upon  hardware /automated  systems 
•jlr'sjcv  in  place  (or  planned  for)  at  MAC  facilities.  These  options  torn  the  basis  lor  the 

definition  of  alternative  systeu  architectures. 
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3.5  Cost/Benefit  Evaluation.  The  objective  of  the  cost/benefit  evaluation  is  to  provide 
the  block  functional  capabilities  as  economically  as  possible  and  to  ensure  that  the  block 
implementation  is  constrained  by  the  budget  as  defined  and  refined  within  the  Economic 
Analysis  document  and  the  Management  Plan,  Volume  1  -  Program  Administration.  A 
Cost/Benefit  Evaluation  is  performed  for  each  segment  and,  if  required,  each  block  withi: 
each  segment.  The  purpose  of  the  evaluation  is  to  document  the  major  analysis  steps  for 
selecting  the  most  cost-effective  means  of  accomplishing  the  AFIRMS  objectives.  The 
first  Cost/Benefit  Evaluation  of  Block  1  implementation  for  each  segment  mav  be 
included  in  a  Segment  Cost/Benefit  Evaluation  document  or  it  can  be  written  as  a 
separate  document.  Regardless,  the  Block  1  Cost/Benefit  Evaluation  must  agree  with, 
and  provide  more  detail  to,  the  recommended  alternative  and  costs  selected  in  the 
Segment  Cost/Benefit  Evaluation.  The  Cost/Benefit  Evaluations  for  succeeding  blocks  in 
each  segment  must  accommodate  prior  Segment  and  Block  Evaluations. 

The  length  and  level  of  detail  in  the  Cost/Benefit  Evaluation  will  depend  on  the  total 
cost  of  the  implementation  alternatives  and  the  level  of  approval  required  in  AFR 
700-series  regulations.  AFR  17S-1,  AFR  1  73- 1  3,  and  AFP  17S-S  guide  the  evaluation 
studv  methods  and  cost  figures. 

3.6  Design  System.  The  system  design  is  the  definition  of  the  relationship  among  the 
hardware  and  software  components  that  accomplish  the  functions  defined  in  the 
functional  architecture.  The  functions  of  the  DBMS,  applications  and  communications 
software,  and  hardware  (if  appropriate)  are  decomposed  into  subordinate  components 
modules.  The  hardware  and  software  modules  are  defined  in  sufficient  detail  to  produce 
the  system/subsystem  specifications.  The  decomposition  of  functions  is  accomplished 
using  structured  "top-down"  techniques,  which  concentrate  on  data  flow,  control,  and 
timing. 

3.7  Define  Installation  Requirements. 

3.7.1  Structures  Affected.  Buildings  scheduled  to  house  new  or  upgraded  equipment,  an e 
specific  room  locations  within  the  buildings,  are  identified  in  this  section.  Once  the 
r.xv’s  are  determined,  the  positioning  of  each  piece  of  equipment  within  the  room  is 
•letaileq  so  that  ttie  site  survey  can  identify  specific  installation  requirements  such  is  the 


access  plan,  location  of  power  plugs,  physical  altering  of  walls,  ceilings  and  floors,  etc. 
This  section  is  updated  once  the  results  of  the  site  survey  are  available,  and  final 
determinations  of  site  installation  configurations  are  accomplished.  Specific 
responsibility  for  structural  modifications  is  assigned  in  this  section. 

3.7.2  Power/Communications/TEMPEST  Requirements.  The  specific  hardware  placed  in 
each  room  determines  electrical  power  requirements  and  equipment  layout  plans  due  to 
possible  TEMPEST  spacing  requirements.  The  power  and  TEMPEST  requirements  for  a 
piece  of  hardware  selected  during  the  development  phase  may  be  determined  by 
referencing  the  manufacturer's  site  preparation  manual  or  similar  document.  These 
documents  provide  the  voltage,  amperage,  and  frequency  requirements  as  well  as  any 
TEMPEST  constraints  which  must  be  observed.  Inter  and  intra  site  communications 
requirements  are  derived  from  the  system  design.  Intra  site  communications  depend  upon 
the  number  of  functional  users  at  the  site  and  the  relationships  between  the  AFIRMS 
products  used  by  these  functional  areas.  Inter  site  communications  requirements  for 
connectivity  are  to  the  higher  level  AFIRMS  site,  to  the  remotely  located  elements  of  the 
site  organization,  and  to  either  the  higher  or  the  remote  elements  as  backup 
connectivity.  After  individual  requirements  are  identified,  they  are  aggregated  by  room 
m  order  to  detail  requirements  by  building.  These  requirements  are  updated  to  reflect 
any  approved  changes  to  the  installation  configuration  identified  during  the  site  survey. 
The  final  content  of  this  section,  in  each  Segment  Plan,  identifies,  or  provides  reference 
to.  the  detailed  electrical  requirements  for  the  installation,  and  assigns  specific 
responsibility  for  achieving  electrical/communications/TEM  PEST  actions  necessary  to  the 
installation. 


3.7,3  Air  Conditioning  Requirements.  Typical  air  conditioning  requirements  may  be 
obtained  from  manufacturers'  site  preparation  manuals  which  are  representative  of  the 
expected  equipment.  These  requirements  are  specified  for  the  main  processor  and  other 
environmentally  sensitive  equipment,  such  as  intelligent  color  graphics  terminals. 
Tombmed-site  air  conditioning  requirements  are  derived  for  use  during  the  site  survey. 
These  requirements,  as  modified  by  the  findings  of  the  site  survey,  specfy  the  air 
'•.mentioning  installation.  Specific  responsibility  for  air  conditioning  services  is  assignee 
this  section. 


3.7.4  Site  Surveys.  Once  the  facility,  power,  air  conditioning,  and  TEMPEST 
requirements  have  been  determined,  site  surveys  are  accomplished.  This  must  be 
scheduled  with  the  appropriate  Engineering  Installation  Group  (EIG)  or  Information 
Systems  Group  well  in  advance  of  the  planned  installation  date.  The  site  surveys 
determine  exactly  what  facility  modifications  are  required  to  accommodate  the  hardware 
configurations.  Details  such  as  equipment  locations,  power  sources,  electrical  lines, 
communications  lines,  and  air  conditioners  are  confirmed.  Site  surveys  must  be  scheduled 
well  in  advance  in  order  to  accommodate  installation,  communications,  and  TEMPEST 
lead  times.  Responsibility  for  site  survey(s)  is  assigned  in  this  section. 

3.8  Prepare  Test/Verification/Validation  Plan.  A  Test/Verification/Validation  Plan  for 
the  segment  applicable  to  each  functional  block  implementation  provides  the  procedures 
by  which  AFIRMS  implementations  are  certified.  To  certify  the  block  implementation,  a 
number  of  actions  are  required.  After  the  site  surveys  have  been  completed  and  the 
system  has  been  installed,  each  site's  system  is  completely  tested,  both  stand-alone  and 
with  other  sites.  The  system  software  and  its  interfaces  with  other  software  modules, 
such  as  the  communications  software  and  the  database,  are  tested  and  verified  to  ensure 
that  they  perform  correctly.  The  communications  lines  between  the  various  sites  also  are 
tested  to  verify  that  data  update  notifications  are  received  when  sent  from  other  sites. 
Also,  data  transfer  from  Wing  level  to  MAJCOM  level  and  MAJCOM  level  to  Air  Staff 
level  is  verified  over  the  actual  communications  lines.  A  test  for  system  load  is 
performed  to  verify  the  capacity  under  which  the  system  can  successfully  run.  In 
addition,  time  tests  are  taken  to  verify  compliance  with  data  transaction  speed 
requirements  for  each  site.  Tests  involving  power  fluctuations  and  alternate  power 
sources  are  performed  to  verify  the  prevention  of  system  loss  due  to  failure  or  inadequacy 
of  backup  power  sources.  Security  tests  and  evaluations  are  integral  parts  of  the 
Test/Verification/Validation  Plan. 

3.9  Prepare  System/Subsystem  Specifications.  Once  the  analysis/requirements  definition 
and  system  design  have  been  completed,  and  the  functional  requirements  for  AFIRMS 
have  been  identified,  they  are  set  forth  in  system,  subsystem,  and  database 
specifications.  These  technical  documents  detail  the  requirements  to  be  satisfied  by  the 
block  implementation  effort. 


The  system  specification  (B-level)  ties  together  the  various  subsystems,  and  defines 
system /subsystem /external  interrelationships  and  interfaces.  The  B-level  specifications 
are  for  syste  ms-wide  requirements  such  as  communications  protocols  and  intersite 
interface  gateways.  Subsystem  and  database  specifications  are  written  (or  updated)  for 
each  system  implementation  site.  These  are  B-level  specifications.  These  specifications 
are  prepared  for  development  personnel,  and  thus  detail  the  environment  and  design 
elements.  Program  specifications  (C-level)  are  provided  as  annexes  to  the  subsystem 
specifications.  All  system /subsystem /database  specifications  are  prepared  in  accordance 
with  appropriate  Air  Force  Automated  Data  Systems  (ADS)  Documentation  Standards. 

The  system /subsystem /database  specifications  provide  a  summary  of  the 
system/subsystem /data  characteristics  and  requirements.  They  contain  a  description  of 
the  system /subsystem  as  well  as  qualitative  and  quantitative  descriptions  of  how  the 
system /subsystem  functions  satisfy  user  requirements.  In  addition,  the  specification 
documents  furnish  descriptions  of  the  following: 

1)  The  equipment  (existing  as  well  as  new  equipment  to  be  procured)  required  for 
the  operation  of  the  system /subsystem. 

2)  The  support  software  (and  test  software,  if  required)  with  which  the  computer 
programs  to  be  developed  must  interact. 

3)  The  interfaces  with  other  applications  computer  programs. 

4)  System  security  considerations  such  as  the  levels  of  availability,  integrity,  and 
confidentiality  of  the  system  and  its  components. 

5)  A  presentation  of  overall  system /subsystem  controls. 

6)  The  operating  procedures  of  the  system. 

7)  The  logical  flow  of  the  system /subsystem. 

8)  System  inputs,  output  and  database. 

9)  The  functions  of  the  computer  programs  in  the  system/subsystem. 
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SECTION  5.  INSTALLATION  PHASE 


5.1  Installation  Procedures  and  Schedule.  Upon  completion  of  the  site  survey,  the 
schedules  for  the  procurement  of  needed  supplies,  electrical  work,  communications  links, 
and  facility  modifications  are  developed.  These  schedules  are  synchronized  with  the 
procurement  of  equipment,  delivery  of  equipment,  and  the  rest  of  the  installation  actions, 
such  as  software  installation  and  training  in  a  master  implementation  plan.  Responsibility 
for  e  tablishing  and  accomplishing  the  installation  schedules  is  assigned  when  the 
schedules  are  established.  Since  the  schedules  were  established  during  the  Development 
Phase,  they  are  first  verified  and  updated  early  in  the  Installation  Phase.  Also,  some  of 
the  more  drastic  facility  modifications  can  be  initiated  during  the  final  efforts  of  the 
Development  Phase. 


5.1.1  Facility  Modification.  Before  hardware  or  communications  equipment  can  be  fully 
installed,  the  facilities  must  be  modified  as  specified  in  the  site  survey. 


5.1.2  Communications  Lines  Installation.  The  schedule  for  running  communications  lines 
can  overlap  the  end  of  facility  modification  schedules,  but  a  functional  area  cannot 
receive  its  lines  until  all  physical  modifications  have  been  performed  at  that  functional 
area's  location  and  at  the  central  node  location.  Ideally,  the  communications  lines 
installations  are  completed  at  the  same  time  as  any  room  modifications  are  done. 


5.1.3  Hardware  Installation.  Hardware  cannot  be  installed  and  unit-tested  at  a  location 
until  the  physical  modifications,  if  any,  are  completed  at  that  location.  Once  the 
communications  equipment  has  been  installed,  a  more  complete  test  of  the  hardware  can 
be  performed. 


34S3I 


G-l  U 


APPENDIX  I.  STRATEGIC  AIR  COMMAND  (SAC)  SEGMENT  PLAN 


SECTION  1.  PURPOSE 

This  appendix  to  the  EIP  provides  the  direction  for  implementing  AFIRMS  at  HQ  SAC. 
This  appendix,  along  with  the  basic  EIP,  provides  the  specific  organization,  detailed 
schedule,  and  responsibilities  for  work  required  to  implement  AFIRMS.  The  reader  should 
refer  to  the  basic  EIP  for  background  information,  overall  schedules,  and  general  system 
analysis/development  guidance.  The  HQ  SAC  appendix  to  the  EIP  is  intended  to  be  a 
given  "living"  document,  and  is  updated  periodically  to  reflect  the  current  HQ  SAC 
implementation  planning. 


SECTION  2.  EVOLUTIONARY  IMPLEMENTATION  PLAN  OVERVIEW 


2.1  Implementation  Elements.  The  SAC  AFIRMS  Segment  Plan  is  composed  of  a  numbe 
of  blocks,  each  with  a  set  of  phases.  Each  block  is  a  specified  set  or  subset  of  AFIRMS 
functional  products  which,  when  implemented,  provide  a  specific  ability  level  within  the 


AFIRMS  functional  capabilities.  AFIRMS  products  are  computer  programs  which 
accomplish  specific  processes  at  a  specified  level  of  detail  within  a  basic  AFIRMS 
function.  A  block  of  AFIRMS  products  is  implemented  by  the  accomplishment  of 
actions  within  five  phases.  These  phases  are: 


specif' 


a.  Analysis/Requirements  Definition 

(Results  in  completion  of  subsystem  specifications) 

b.  Development 

(Results  in  completion  of  integrated/tested  program  coding) 

c.  Installation 

(Results  in  site  installations  of  hardware  and  software) 

d.  Operations 

(Results  in  use  of  the  installed  block  capabilities) 

e.  Systems  Integration/Management 

(Results  in  coordinated  accomplishment  of  all  phases  of  the  block  and  in 
adherence  to  the  AFIRMS  Management  Plan). 


2.2  Schedule.  The  overall  SAC  implementation  plan  is  shown  in  Figure  2-1. 
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Figure  2-1.  SAC  Block  1  Phase  Schedule 


SECTION  3.  ANALYSIS/REQUIREMENTS  DEFINITION  PHASE 


3.1  Survey  Users.  The  Analysis/Requirements  Definition  Phase  consists  of  those  steps 
necessary  to  design  and  specify,  in  detail,  the  functional  needs  programmed  for  a  block  in 
the  EIP.  These  steps  are  the  identification  or  confirmation  of  metrics,  the  design  of  the 
functional  architectures  with  associated  cost  benefit  analysis,  system  design,  installation 
planning,  and  preparation  of  specifications.  Survey  efforts  identify  functional  users  of* 
AFIRMS,  identify  general  functional  requirements,  accomplish  the  preliminary  facilities 
survey,  and  facilitate  communication  between  the  systems  developer  and  the  end  user(s) 
of  the  system.  Visits  to  work  locations  are  accomplished  to  gain  first-hand  knowledge  of 
the  users'  requirements  and  their  contextual  environment.  Upon  arrival  at  the  survey 
site,  the  analysts  conduct  an  in-briefing  to  inform  the  AFIRMS  project  officer  and  other 
key  personnel  of  the  reason  for  the  visit  and  the  goals  of  the  user  survey.  The  analysts 
use  whatever  tools  are  necessary  to  survey  the  users.  Examples  are: 


a.  The  use  of  questionnaires.  Questionnaires  provide  a  means  of  collecting  consistent 
sets  of  information  from  a  large/number  of  people  in  a  short  period  of  time. 

b.  Interviewing.  Interview  questions  lead  to  discussions  about  the  current  and  desired 
future  systems,  both  formal  and  informal.  The  analysts  interview  a  cross  section 
of  the  personnel  to  get  a  good  feel  for  the  users'  operation  and  the  spectrum  of 
user  requirements. 

c.  Review  of  Management  Indicators.  Organizations  use  a  variety  of  indicators  to 
assign  tasking  and  measure  productivity,  capability,  and  performance.  The  analysts 
inventory  those  indicators  carefully  to  determine  their  use,  the  source  of  data, 
methods  of  compilation,  and  relevance  as  possible  AFIRMS  metrics. 

d.  Preliminary  Analysis  of  the  Facilities.  The  analysts  note  the  working 
environment.  Many  operations  are  scattered  among  several  locations.  The 
analysts  determine  the  method  of  communication  and  the  interface  requirements 
between  operations  occurring  at  separate  locations.  Preliminary  identification  of 
available  facilities,  power  sources,  air  conditioning,  and  access  routes  is 
accomplished. 


When  the  survey  is  finished,  the  analyst  team  leader  conducts  an  exit  briefing  with 
the  AFIRMS  project  office  and  key  personnel  within  the  organization. 


3.2  Identify/Confirm  Metric(s).  During  the  survey  of  the  users,  the  unit's  standards  or 
indicators  that  measure  tasking  and  performance  are  identified.  The  rationale  for  the 
metric,  the  source(s)  of  information,  and  the  use  of  particular  indicators  or  standards  by  3 


higher  headauarters  are  determined.  Some  metrics  may  be  for  local  use  only.  Other 
metrics  are  passed  to  higher  headquarters  for  consolidation,  analysis,  and  decision  support. 
Other  indicators  or  standards  may  be  used  as  productivity  measures.  These  indicators  or 
standards  are  of  primary  importance  to  AFIRMS.  They  integrate  resource  requirements  to 
achieve  the  desired  mission  results.  As  an  example,  the  metric  for  tactical  air  forces  is 
the  sortie.  The  sortie  integrates  the  essential  resource  components  of  a  mission  (aircraft, 
aircrew,  fuels,  and  missions).  It  also  provides  a  focus  for  the  application  of  generative 
resources  (such  as  spares)  which  are  elemental  to  providing  the  basic  aircraft  resource. 


3.3  Design  Functional  Architecture.  The  design  of  the  SAC  Block  I  functional 
architecture  will  provide  for  the  tailoring  of  core /basic  AFIRMS  functional  capabilities  to 
SAC-unique  needs  where  applicable,  and  the  development  of  new  functional  products  as 
required. 


A  functional  analysis  of  all  potential  SAC  AFIRMS  users  determines  how  different 
types  of  resource  data  affect  the  capability  of  a  Wing's  mission,  and  how  the  different 
users  (Wings,  MAJCOMs,  and  the  Air  Staff)  use  the  same  data  for  their  particular 
purposes.  A  structured,  "top-down"  approach  is  taken  for  the  functional  architectural 
design  once  the  "bottom-up"  requirements  analysis  has  been  accomplished.  All  functional 
areas  are  broken  down  to  sub-functions  in  enough  detail  to  describe  the  relevant  activities. 
In  examining  a  function,  the  analyst  gives  specific  attention  to  the  interfaces,  both  into 
and  out  of  the  functional  areas.  Analysis  also  determines  the  organization  element  which 
controls  the  various  activities.  Availability  and  sufficiency  of  both  existing 
communications  and  existing  automated  data  systems  establish  constraints  and 
requirements  for  the  functional  architecture.  The  functional  architecture  design  provides 
the  framework  for  the  development  of  system  design,  specifications,  and  database 
structure.  Specific  steps  necessary  for  functional  architectural  design  are  describee  in 
subsequent  subsections. 


3.3.1  Select  AFIRMS  Products.  AFIRMS  Products,  which  have  been  developed,  relate  to: 


a.  Unit  and  base  level  status  information 

b.  W ing  level  resource  status  summary 

c.  Capability  assessment  model  (sortie  generation) 

d.  Integrated  resource  capability  assessment 

e.  Individual  resource  capability  assessment 
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f. 


Dollar  costing  of  resource  allocations  against  requirements 
"Optimization"  of  dollar  allocation  among  resources  to  maximize  capability. 


g- 

After  the  requirement  analysis,  the  available  AFIRMS  products  are  reviewed  to  see  if 
they  can  meet,  or  be  modified  to  meet,  the  various  functional  requirements. 

The  functional  architecture  includes  existing  or  modified  AFIRMS  products,  if 
applicable.  Use  of  those  products  reduces  the  system  development  time  considerably  and 
avoids  duplication  of  developmental  efforts. 


3.3.2  Design  Additional  Products.  The  user  survey(s)  may  identify  new  functional 
requirements  for  which  AFIRMS  products  are  not  yet  developed.  As  the  user  identifies 
requirements  that  have  not  been  previously  defined,  the  analyst  will  design  application 
modules  for  the  new  products  based  upon  thorough,  detailed  functional  requirements 
analysis.  It  should  be  emphasized  that  these  are  NEW  products  which  MAY  be  deferred 
for  implementation  in  subsequent  functional  block  product  development  phases. 

The  functional  analysis  that  establishes  the  functional  architecture  will  also  identify 
SAC  unique  requirements.  These  command  unique  requirements  are  likely  to  be  the 
primary  source  of  new  AFIRMS  products.  These  new  products  are  identified,  designed, 
and  specified  to  a  level  of  detail  that  will  allow  program  coding  to  proceed. 


3.3.3  Define/Design  Interfaces.  SAC  AFIRMS  Block  2  will  interface  with  WWMCCS  and 
DDN/AUTODIN  for  communications  with  HQ  USAF  and  other  major  commands,  and  those 
Air  Force  functional  systems  identified  during  the  Block  1  Analysis  Phase. 

Very  few,  if  any,  functional  areas  operate  in  isolation.  During  the  survey  of  users, 
interfaces  will  become  apparent.  There  are  inter-  and  intra-functional  interfaces. 
Intra-functional  interfaces  are  internal  to  AFIRMS  or  AFIRMS  users/sites.  An 
inter-functional  interface  is  one  outside  of  AFIRMS.  The  interfunctional  interface  will 
link  AFIRMS  with  other  Air  Force  functional  areas  and/or  automated  systems.  While  the 
user  survey  will  uncover  the  obvious  interfaces,  less  obvious  interfaces  may  be  identified 
in  the  design  of  the  functional  architecture,  .nd  detailed  systems  specifications.  These 
interfaces  are  documented,  specified,  and  included  in  the  design  of  AFIRMS.  The 
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specifications  identify  the  method  of  interface  (air  gap,  tape-to-tape,  hardwire)  along 
with  the  impact  which  the  interface  has  on  the  users  of  both  AFIRMS  and  the  external 
sy stem(s). 

3.3.4  Define  Functional  Baseline.  The  functional  baseline  for  SAC  Block  2  is  the  set  of 
core  AFIRMS  functional  capabilities  adapted  for  support  of  SAC  functional  requirements. 

This  is  the  contract  between  the  user  and  developer.  The  functional  baseline  includes 
all  the  requirements  identified  in  the  user  survey  and  requirements  analysis  efforts,  to 
include  the  metrics  and  any  new  applications.  To  ensure  the  accuracy  of  the  information, 
the  baseline  is  certified  by  the  HQ  USAF  and  M  A  3COM  configuration  control  authorities 
before  any  development  work  starts.  With  baseline  certification,  the  OPR/PMO  team 
assumes  responsibility  for  new-  block  development.  Any  enhancement  to  the  block 
functionality,  change  in  requirements,  or  additional  development  efforts  must  be  approved 
by  the  configuration  control  authorities. 

3.3.5  Design/Size  Database.  Design  of  the  AFIRMS  segment  database  consists  of  three 
stages:  conceptual  design,  logical  design,  and  physical  design.  A  complete  understanding 
of  the  relationships  that  exist  for  all  data  in  a  segment  is  needed  for  the  conceptual 
design.  Next,  the  conceptual  database  design  is  mapped  into  a  series  of  logical  database 
designs  from  each  different  user's  perspective.  The  physical  design  and  implementation 
of  this  logical  design  follow,  with  the  peculiarities  of  the  chosen  DBMS  establishing 
essential  guidelines  as  to  the  actual  structure  of  the  data. 

The  logical  database  design  does  not  normally  change  within  a  MA3COM  segment 
unless  new  information  has  been  gathered.  From  the  outset,  it  should  reflect  similarities 
that  exist  in  all  MAJCOMs  for  maximum  consistency  from  segment  to  segment.  Minor 
changes  to  the  database  design,  and  to  the  software  that  accesses  it,  are  to  be  expected. 

Likewise,  the  logical  designs  should  reflect  as  much  similarity  between  segments  as  is 
possible.  Here,  even  more  variation  is  expected  because  of  some  of  the  fundamental 
differences  that  exist  among  MAJCOMs.  For  sites  within  a  segment,  excluding  the 
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VAjCOM  HC.  there  should  be  little,  if  any,  change  to  the  logical  cesigns.  That  is  To  sa\, 
all  wings  tvpically  have  the  same  functional  areas  and,  conseauently,  AFIRViS  cata 
recuirements  within  those  functional  areas  are  the  same.  This  assumption  is  prebabK 
accurate  for  the  most  part,  but  minor  exceptions  should  be  expected. 

\X  chin  3  MAJCOM  segment,  the  physical  implementation  of  each  site's  database  is 
likelv  to  varv  depending  on  the  priority  of  individual  needs.  Thus,  the  database  is 
optimized  with  available  DBMS  tuning  mechanisms  to  better  support  products  favored  at 
that  site.  A  goal  of  these  optimizations  is  that  very  little  or  no  change  need  be  made  to 
existing  AFIRMS  software  at  that  site. 

The  conceptual  and  logical  database  design  stages  of  the  AFIRMS  database  at  any 
given  site  in  a  particular  segment  will  occur  in  the  Analysis/Requirements  Definition 
Phase  of  the  initial  implementation.  Known  data  requirements  of  all  functional  areas  of 
each  site  are  accommodated  during  this  phase.  Logical  database  changes  can  cause  major 
database  design  modifications  across  the  board.  Likewise,  switching  from  one  DBMS  to 
another  cannot  be  readily  accommodated.  Modifications  to  the  physical  design  of  the 
AFIRMS  databases  within  a  segment,  on  the  other  hand,  continue  for  tuning  purposes  and 
shoulc  pose  no  major  problem. 

Sizing  estimates  are  gathered  during  each  design  stage,  approaching  more  realistic 
numbers  as  the  design  progresses.  A  reasonable  sizing  estimate  is  achievable  after  the 
logical  design  stage,  since  all  data  requirements  are  defined.  Once  again,  it  is  reasonable 
to  suggest  that  the  sizing  estimates  shoulc  not  vary  greatly  from  one  site  to  another 
w  ithin  a  segment,  unless  one  site  possesses  mam  more  resources  than  others.  After  a 
particular  DBMS  is  chosen  for  use  within  a  segment,  the  most  accurate  database  sizing 
estimate  can  be  made  since  actual  data  storage  needs  can  be  assessed  and  the  amount  of 
software  which  accesses  that  DBMS  can  be  better  estimated. 

3,4  Define  Alternative  Architecture.  Suitable  options  for  the  design  of  the  SAC  Block  2 
svstem  architecture  are  dependent  to  a  great  extent  upon  hardware/automated  systems 
a  I  read  v  in  plane  (or  planned  for)  at  SAC  f  anilities.  These  options  form  the  basis  for  the 
definition  of  alternative  svstem  arnhitentures. 


3.5  Cost/Benefit  Evaluation.  The  objective  of  the  cost/benefit  evaluation  is  to  provide 
the  block  functional  capabilities  as  economically  as  possible  and  to  ensure  that  the  block 
implementation  is  constrained  by  the  budget  as  defined  and  refined  within  the  Economic 
Analysis  document  and  the  Management  Plan,  Volume  1  -  Program  Administration.  A 
Cost/Benefit  Evaluation  is  performed  for  each  segment  and,  if  required,  each  block  within 
each  segment.  The  purpose  of  the  evaluation  is  to  document  the  major  analysis  steps  for 
selecting  the  most  cost-effective  means  of  accomplishing  the  AF1R.MS  objectives.  The 
first  Cost/Benefit  Evaluation  of  Block  1  implementation  for  each  segment  may  be 
included  in  a  Segment  Cost/Benefit  Evaluation  document  or  it  can  be  written  as  a 
separate  document.  Regardless,  the  Block  1  Cost/Benefit  Evaluation  must  agree  with, 
and  provide  more  detail  to,  the  recommended  alternative  and  costs  selected  in  the 
Segment  Cost/Benefit  Evaluation.  The  Cost/Benefit  Evaluations  for  succeeding  blocks  in 
each  segment  must  accommodate  prior  Segment  and  Block  Evaluations. 

The  length  and  level  of  detail  in  the  Cost/Benefit  Evaluation  will  depend  on  the  total 
cost  of  the  implementation  alternatives  and  the  level  of  approval  required  in  AFR 
700-series  regulations.  AFR  173-1,  AFR  173-13,  and  AFP  173-8  guide  the  evaluation 
study  methods  and  cost  figures. 

3.6  Design  System.  The  system  design  is  the  definition  of  the  relationship  among  the 
hardware  and  software  components  that  accomplish  the  functions  defined  in  the 
functional  architecture.  The  functions  of  the  DBMS,  applications  and  communications 
software,  and  hardware  (if  appropriate'  are  decomposed  into  subordinate  components 
modules.  The  hardware  and  software  modules  are  defined  in  sufficient  detail  to  produce 
the  system/subsystem  specifications.  The  decomposition  of  functions  is  accomplished 
using  structured  "top-dowm"  techniques,  which  concentrate  on  data  flow,  control,  and 
timing. 


3.7  Define  Installation  Requirements. 


3.7.1  Structures  Affected.  Buildings  scheduled  to  house  new  or  upgraded  equipment,  ana 
specific  room  locations  within  the  buildings,  are  identified  in  this  section.  Once  the 
rooms  are  determined,  the  positioning  of  each  piece  of  equipment  within  the  room  is 
detailed  so  that  specific  installation  requirements  can  be  determined:  i.e.,  access  plan, 


location  of  power  plugs.  physical  altering  of  walls,  ceilings,  and  floors,  etc.  These 
requirements  are  updated  once  the  results  of  the  site  survey  are  availaole,  and  final 
oeter  notations  of  site  installation  configurations  are  accomplished.  Specific 
resoonsioilin  for  structural  modifications  is  assigned  in  this  section. 

✓ 

3.7.2  Power/Communications/TEMPEST  Requirements.  The  specific  hardware  placed  in 
each  room  determines  electrical  power  requirements  and  equipment  layout  plans  due  to 
possible  TEMPEST  spacing  requirements.  The  power  and  TEMPEST  requirements  for  a 
piece  of  hardware  selected  during  the  development  phase  may  be  determined  by 
referencing  the  manufacturer's  site  preparation  manual  or  similar  document.  These 
documents  provide  the  voltage,  amperage,  and  frequency  requirements  as  well  as  any 
TEMPEST  constraints  which  must  be  observed.  Inter  and  intra  site  communications 
requirements  are  derived  from  the  system  design.  Intra  site  communications  depend  upon 
the  number  of  functional  users  at  the  site  and  the  relationships  between  the  A  FIR  MS 
products  used  by  these  functional  areas.  Inter  site  communications  requirements  for 
connectivity  are  to  the  higher  level  AFIRMS  site,  to  the  remotely  located  elements  of  the 
site  organization,  and  to  either  the  higher  or  the  remote  elements  as  backup 
connectivity.  After  individual  requirements  are  identified,  they  are  aggregated  by  room 
in  order  to  detail  requirements  by  building.  These  requirement s  are  updated  to  reflect 
any  approved  changes  to  the  installation  configuration  identified  during  the  site  survey. 
The  final  content  of  this  section,  in  each  Segment  Plan,  identifies,  or  provides  reference 
to.  tne  detailed  electrical  requirements  for  the  installation,  and  assigns  specific 
responsibility  for  achieving  electrical/communications/TEMPEST  actions  necessary  to  the 
installation. 


3,7.3  Air  Conditioning  Requirements.  Typical  air  conditioning  requirements  may  be 
obtained  from  manufacturers'  site  preparation  manuals  which  are  representative  of  the 
expected  equipment.  These  requirements  are  specified  lor  the  main  processor  and  other 
environmentally  sensitive  equipment,  such  as  intelligent  color  graphics  terminals. 
Combined-site  air  conditioning  requirements  are  derived  for  use  during  the  site  survey. 
These  requirements,  as  modified  bv  the  findings  of  the  site  survey,  specify  the  air 
conditioning  installation.  Specific  responsibility  for  air  conditioning  services  is  assigned 
in  this  section. 


3.7.4  Site  Surveys.  Once  the  facility,  power,  air  conditioning,  and  TEMPEST 
requirements  have  been  determined,  site  surveys  are  accomplished.  This  must  be 
scheduled  with  the  appropriate  Engineering  Installation  Group  (E1G)  or  Information 
Systems  Group  well  in  advance  of  the  planned  installation  date.  The  site  surveys 
determine  exactly  what  facility  modifications  are  required  to  accommodate  the  hardware 
configurations.  Details  such  as  equipment  locations,  power  sources,  electrical  lines, 
communications  lines,  and  air  conditioners  are  confirmed.  Site  surveys  must  be  scheduled 
well  in  advance  in  order  to  accommodate  installation,  communications,  and  TEMPEST 
lead  times.  Responsibility  for  site  survey(s)  is  assigned  in  this  section. 


3.8  Prepare  Test/Verification/Validation  Plan.  A  Test/Verification/Validation  Plan  for 
the  segment  applicable  to  each  functional  block  implementation  provides  the  procedures 
by  which  AFIRMS  implementations  are  certified.  To  certify  the  block  implementation,  a 
number  of  actions  are  required.  After  the  site  surveys  have  been  completed  and  the 
system  has  been  installed,  each  site's  system  is  completely  tested,  both  stand-alone  and 
with  other  sites.  The  system  software  and  its  interfaces  with  other  software  modules, 
such  as  the  communications  software  and  the  database,  are  tested  and  verified  to  ensure 
that  they  perform  correctly.  The  communications  lines  between  the  various  sites  also  are 
tested  to  verify  that  data  update  notifications  are  received  when  sent  from  other  sites. 
Also,  data  transfer  from  Wing  level  to  MA3COM  level  and  MAJCOM  level  to  Air  Staff 
level  is  verified  over  the  actual  communications  lines.  A  test  for  system  load  is 
performed  to  verify  the  capacity  under  which  the  system  can  successfully  run.  In 
addition,  time  tests  are  taken  to  verify  compliance  with  data  transaction  speed 
requirements  for  each  site.  Tests  involving  power  fluctuations  and  alternate  power 
sources  are  performed  to  verify  the  prevention  of  system  loss  due  to  failure  or  inadequacy 
of  backup  power  sources.  Security  tests  and  evaluations  are  integral  parts  of  the 
Test/Verif ication/Validation  Plan. 


3.9  Prepare  System/Subsystem  Specifications.  Once  the  analysis/requirements  definition 
and  system  design  have  been  completed,  and  the  functional  requirements  for  AFIRMS 
have  been  identified,  they  are  set  forth  in  system,  subsystem,  and  database 
specifications.  These  technical  documents  detail  the  requirements  to  be  satisfied  by  the 
block  implementation  effoit. 
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The  system  specification  (B-ievel)  ties  together  the  various  subsystems,  ana  defines 
svstem /subsystem /externa  1  interrelationships  ana  interta«;es.  The  B-leve!  specifications 
are  for  svstems-wide  requirements  such  as  <■  imm^tior  s  pp'r'S'ls  arc  intersite 
interface  gateways.  Subsystem  and  database  sp#*<’iti<  j>o' s  jr>-  w  ritten  for  updated)  for 
each  system  implementation  site.  These  are  s-  .<•  ; : .tiers.  T ".e$e  specifications 

are  prepared  for  development  personnel,  arc  M-us  <'»>•  :.•••■  Mr  -n  «-t  .,nc  design 
elements.  Program  specifications  (C-leve!)  are  prove:-.-  ■  r  -  m  tre  subsystem' 
specifications.  All  system /subsystem /database  spec  it  m  jt  m.  s  are  prepared  in  accordance 
with  appropriate  Air  Force  Automated  Pat  a  Xyster  s  i  -VPx)  |\>  m-  eptation  Standards. 

The  system /subsystem /database  specif  icatiors  provide  a  sumn  ary  of  the 
svstem /subsystem /data  characteristics  and  requirements.  They  contain  a  description  of 
the  system /subsystem  as  well  as  qualitative  and  quantitative  descriptions  of  how  the 
system/subsystem  functions  satisfy  user  requirements.  In  addition,  the  specification 
documents  furnish  descriptions  of  the  following: 

1)  The  equipment  (existing  as  well  as  new  equipment  to  be  procured)  required  for 
the  operation  of  the  system  /subsystem. 

2)  The  support  software  (and  test  software,  if  required)  with  which  the  computer 
programs  to  be  developed  must  interact. 

3)  The  interfaces  with  other  applications  computer  programs. 

'A  System  security  considerations  such  as  the  levels  of  availability,  integrity,  and 
confidentiality  of  the  system  and  its  components. 

5)  A  presentation  of  overall  system /subsystem  controls. 

6)  The  operating  procedures  of  the  svstem. 

7)  The  logical  flow  of  the  system /subsystem. 

8)  Svstem  inputs,  output  and  database. 

9)  The  functions  of  the  computer  programs  in  the  system /subsystem. 
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SECTION  5.  INSTALLATION  PHASE 
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5.1  Installation  Procedures  and  Schedule.  Upon  completion  of  the  site  survey,  the 
schedules  for  the  procurement  of  needed  supplies,  electrical  work,  communications  links, 
and  facility  modifications  are  developed.  These  schedules  are  synchronized  with  the 
procurement  of  equipment,  delivery  of  equipment,  and  the  rest  of  the  installation  actions, 
such  as  software  installation  and  training  in  a  master  implementation  plan.  Responsibility 
for  establishing  and  accomplishing  the  installation  schedules  is  assigned  when  the 
schedules  are  established.  Since  the  schedules  were  established  during  the  Development 
Phase,  they  are  first  verified  and  updated  early  in  the  Installation  Phase.  Also,  some  of 
the  more  drastic  facility  modifications  can  be  initiated  during  the  final  efforts  of  the 
Development  Phase. 


5.1.1  Facility  Modification.  Before  hardware  or  communications  equipment  can  be  fully 
installed,  the  facilities  must  be  modified  as  specified  in  the  site  survey. 


5.1.2  Communications  Lines  Installation.  The  schedule  for  running  communications  lines 
can  overlap  the  end  of  facility  modification  schedules,  but  a  functional  area  cannot 
receive  its  lines  until  all  physical  modifications  have  been  performed  at  that  functional 
area's  location  and  at  the  central  node  location.  Ideally,  the  communications  lines 
installations  are  completed  at  the  same  time  as  any  room  modifications  are  done. 


5.1.3  Hardware  Installation.  Hardware  cannot  be  installed  and  unit-tested  at  a  location 
until  the  physical  modifications,  if  any,  are  completed  at  that  location.  Once  the 
communications  equipment  has  been  installed,  a  more  complete  test  of  the  hardware  can 
be  performed. 
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